Does D need standard locations?

[Johannes Pfau via Digitalmars-d]

Am Sun, 1 Feb 2015 18:58:03 +0000
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d at puremagic.com>:

> 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.
> 

Sounds good, I think the fact that we need dub to build anything is not
a feature but rather embarrassing. A layout as in C++ with a
system-wide include directory makes sense. The real problem is actually
with libraries as long as compilers are not ABI compatible. We can't
really do anything about that though. While static libraries could be
moved to different folder (like dub does) this approach doesn't work
for shared libraries.

include-fixed is kinda C++ specific though, how would we use that for
D headers?