Does D need standard locations?

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Mon Feb 2 05:24:09 PST 2015


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



More information about the Digitalmars-d mailing list