On 2013-11-21 14:11, Bruno Medeiros wrote:
These solutions involving dub using external/system package managers
don't feel right at all... I think this is a wrong approach.Doesn't using external libraries imply you need a D binding/import
anyways? As such doesn't it follow that it is best that an external
library be wrapped by a dub-package? Here's the idea:
The dub-package wrapper would include the library binaries (for all
available platforms) and the respective D imports/bindings. This would
make the library available for dub usage in all platforms, with no
reliance on system package managers (thus, cross-platform).
If a newer version of the library is made available (say, you have a
dub-package for curl-1.2.3 and now 1.2.4 is out, then the dub-package
will have to be manually updated. Some auxilary tool could be used to
help with this process. This tool could potentially interact with a
system package manager, but it would be separate from dub (or sitting at
a higher level in the toolchain).This approach requires more work to update libraries when new versions
arrive, but it's easier to implement (dub-wise) and provides a clean
platform-independent abstraction, because dub remains independent of
system package managers.
I think it's a worth tradeoff. In any case, any library updates other
than service-level version updates will (or should) require an update to
the D bindings since it means the underlying API has changed.
Just take a look at the current issues with Curl for DMD. It's not very
easy to make a library work across all different flavors of Linux.
/Jacob Carlborg