Does D need standard locations?

[Johannes Pfau via Digitalmars-d]

Am Mon, 2 Feb 2015 13:24:09 +0000
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d at puremagic.com>:

> On 2 February 2015 at 13:20, Iain Buclaw <ibuclaw at gdcproject.org>
> wrote:
> > On 2 February 2015 at 09:53, Johannes Pfau via Digitalmars-d
> > <digitalmars-d at puremagic.com> wrote:
> >> 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?
> >>
> >
> > I guess maybe for gcc-specific C bindings?  In any case nothing that
> > can't be fixed with versioning.
> 
> The alternative to my patch above is to just use one location for
> everything:
> 
> $(libsubdir)/include/d
> 
> Which guarantees to have the target and version directories to
> separate it from any other gdc installations.
> 
> Iain
> 

I'd prefer the other scheme.
In the end it's simple enough to not store any D headers in /usr if you
don't want GDC to include them.

But having a standard location makes many things easier.
apt-get install msgpack-d then opening MonoDevelop, simply importing
msgpack without ever adding include paths and compiling requires only
adding only a single -lmsgpack, ...