Ricardo Wurmus <[email protected]> skribis: > Ludovic Courtès <[email protected]> writes: > >> Ben Woodcroft <[email protected]> skribis: >> >>> But would it be possible to include the scripting language bindings, >>> something along these lines? >>> >>> + (arguments >>> + `(#:configure-flags '("--enable-ruby-binding" >>> + "--enable-python-binding" >>> + "--enable-perl-binding") >> >> There’s the usual space/popularity tradeoff to take into account: adding >> them all makes the package’s closure much larger, so it’s important to >> add only the useful bindings by default. >> >> Ideally, the .so for these bindings could be moved to separate outputs >> (like we did for the “tk” output of Python), but it’s not always easy to >> do. > > In this case it seems to be very easy to separate the bindings into > different outputs as the flags take an optional path.
Great. > However, the test for the Perl bindings does not pass: > > /gnu/store/czs63sm4l0s4a56ab38dqvkx19yzylbq-perl-5.16.1/bin/perl: symbol > lookup error: > /tmp/nix-build-jellyfish-2.2.4.drv-0/jellyfish-2.2.4/.libs/libjellyfish-2.0.so.2: > undefined symbol: pthread_create > FAIL tests/swig_perl.sh (exit status: 127) > > Maybe the library needs another linker flag? I’ll play with this later > and see if I can make it work. If not I’ll leave the Perl bindings (and > the “perl” output) away for now. Looks like libjellyfish-2.0.so lacks “-pthread” in its LDFLAGS. Perl dlopening reveals the problem, it seems. > It’s a bit unfortunate that this library would gain so many transitive > inputs just for these bindings (all of these three languages require a > lot of inputs). It would be nice if we could somehow mark certain > inputs to be used only for certain outputs, but that’s probably a silly > wish. At least someone using substitutes won’t need to download all these prerequisites if bindings are moved to individual outputs. Thanks, Ludo’.
