On 24/11/2013 20:22, Jacob Carlborg wrote:
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.
I noticed the thread but didn't look into it, it is too big. I just took
a quick glance at some of the posts. I reckon there's issues with
regards to how the Curl lib links to libc and other dependency
libraries, is that it?
Yeah, that kind of stuff - interactions between the C libs themselves -
makes it very complicated for us to ship (and maintain) dub-packages
wrapping C libraries. But still I think the alternative seems just as
bad, if not worse.
What about an intermediate approach for Dub, where a Dub package could
check in a sane way if it is possible to link against a certain C
library (for example, trying to compile and run a dummy internal
project)? And the dub package wrapper would be just that. It would fail
in a sane way, but it wouldn't actually try to install the library.
How does Python deal with this BTW, anyone familiar? I think Python is
interesting to look at because it has binding to a lot of C-libraries,
so it must have encountered the same problem.