Make dub part of the standard dmd distribution

[Johannes Pfau via Digitalmars-d]

Am Mon, 1 Jun 2015 15:26:51 +1000
schrieb Manu via Digitalmars-d <digitalmars-d at 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.