Does D need standard locations?

[Iain Buclaw via Digitalmars-d]

On 2 February 2015 at 17:22, Johannes Pfau via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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, ...
>

OK - going to plough ahead with updating libphobos configure scripts then.

By the way, any last word on https://github.com/D-Programming-GDC/GDC/pull/92 ?

Iain.