RejectedSoftware Forums

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.

On 2013-11-29 13:26, Bruno Medeiros wrote:

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?

Actually no. Although that could be another problem. In this case it's
because libcurl on Debian has different symbol names from libcurl on
other distributions. On Debian the SSL implementation, OpenSSL or Gnu
TLS, is mangled in the symbol names. That's not the case on Fedora.

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.

I don't know about Python but Ruby just assumes the native library is
available in the standard paths. Although Ruby builds the bindings when
installing the gem, so you won't have that problem at least.

/Jacob Carlborg