Does D need standard locations?

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


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.



More information about the Digitalmars-d mailing list