Does D need standard locations?

[Iain Buclaw via Digitalmars-d]

Hi,

Next list of things that need sorting out™ in GDC is how the compiler
works out where module interfaces are installed vs. where the library
actually installed them - this is tricky when taking into
consideration:

- There may be multiple versions installed.
- It may be a cross compiler.
- It may support multiarch/multilib configuration (-m32, -mx32, -m64).
- The compiler may have been relocated (Think 'DESTDIR=/relocate make install')

Traditionally, we've gone for the following two locations to look for
D sources (ignoring cross compilers for the moment).

/usr/include/d/$(version)
/usr/include/d/$(version)/$(target)/$(multilib)

And satisfying all considerations with the above structure has been a
challenge with some clever script tomfoolery to make it *look* like
the compiler build and library configure scripts are in parity.

So, I aim to fix that, and the first point of reference to go for
without making additional patches to gcc is to re-use C's header
structure, tacing "/d" on the end.

First draft is in this branch here:
https://github.com/ibuclaw/GDC/compare/fix_includes

Which changes the search paths to the following locations (expanded
out all /../'s to make it readable):

/usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)
/usr/local/include/d/$(multilib)
/usr/lib/gcc/$(host)/$(version)/include-fixed/d
/usr/$(target)/include/d
/usr/include/d

While it is quite clear that druntime/phobos sources shipped with GDC
will soon be installed in the library directories.  This introduces
some interesting new behaviours (if you're not running Windows, at
least).  Suddenly, you can install a D source file in any of the
system, local, or target include directories, and it will be
automatically picked up by the compiler.

However, this may not be a good thing.  The way we are going with
dealing with D libraries - it looks like the only way is Dub and
introducing this *now* brings nothing to the table.

And even if Dub isn't your first choice of package system, then you'd
probably still not care in the slightest as we're all now so far in
being used to not following in the C/C++ tradition of library
installations, each and every one of us (and our dog) has likely
invented our own scheme that suits us, then changed the configuration,
or did a bespoke build to match your set-up.

Regardless, this is much better for GDC, and allows for hundreds of
deletions in scripts to follow, not to mention offloading the logic of
*where* things should be installed back to GCC.  So for the time
being, we say 'Hello' to the traditional idioms of last century, and
see what abuse scales from there.

Iain.