Am Mon, 1 Jun 2015 15:26:51 +1000 schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
> So, DMD/LDC/GDC know where to look to find these packages? IIRC no. > What > happens if the package includes a binary lib? > > That that, I still want someone to declare an official path for D > 'includes' in the *nix filesystem, so D lib packages have somewhere to > install... GDC looks in /usr/include/d2. Dicebot changed that to /usr/include/d/gdc for archlinux and there are some reasons why this is (for now) necessary: Sharing D sources/headers between compilers is possible, but there are some headers (druntime,phobos) which can be compiler specific. As long as these are not in a common import path it's not a problem though. The main problem is we don't have ABI compatibility. This means we can't share the libraries between compilers. So we could make 'import foo' work but linking with -lfoo without manually adjusting linker paths is not possible. There are some solutions, all have drawbacks: * Have compiler specific directories for libraries (/usr/lib/gdc/libvibed.a, /usr/lib/dmd/libvibed.a). Only works for static libraries. Can only have one version of a library installed * have per-library directories. I guess dub uses this. Can have multiple versions of the same library. Drawback: compiler can't know the correct library path.[1] * Shared libraries should be installed in a common location (/usr/lib) anyway. This is only possible if we have ABI compatibility[2]. Library versioning is limited to the standard C/C++ like versioning. I guess the main reason why we can't have a C/C++ like out of the box experience is ABI compatibility. There'll always be some quirks as long as we don't fix this. [1] you could actually build the directory structure logic into the compilers. Do something like dmd --library=vibe.d:0.7.23 where this argument sets up correct import paths and linking. I think .NET uses something similar (GAC). With ABI compatible compilers we might even make this work for shared libraries. Could be implemented as a small tool calling the compiler. You could also do something like this: Create a package format: .dlib (simply a renamed .tar.xz) Contents: - PACKAGEINFO //meta information (version) - include/* //include files - doc/* //documentation in standard format for IDEs - lib/dmd/libfoo.a - lib/gdc/libfoo.a Write a small tool xdmd. Implement: //simply move to /usr/share/dlib/libfoo/version/ //or ~/.share/dlib/libfoo/version/ xdmd --install libfoo.dlib Note: when installing using a systems package manager, packages could be installed in the same way: pacman -S libfoo could call xdmd --install. //extract /usr/share/dlib/libfoo/0.9.3/libfoo.dlib //to temporary directory. Pass link and include flags and //rest of arguments to dmd xdmd --library=foo:0.9.3 test.d //directly use local package xdmd --library=libfoo-0.9.3.dlib test.d This is essentially are very slimmed down dub. Would be a nice weekend exercise to write such a tool. [2] or you use one compiler exclusively.