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.

On Sunday, 1 February 2015 at 18:58:22 UTC, Iain Buclaw wrote:
> - It may be a cross compiler.
> - It may support multiarch/multilib configuration (-m32, -mx32, -m64).

AFAIU those are effectively non-existent in D and expected to be handled with internal version blocks, not file system differentiation during installation.

> - The compiler may have been relocated (Think 'DESTDIR=/relocate make install')

Why does it matter?

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

I use simply /usr/include/dlang/<compiler-name> in Arch for now (because versions are irrelevant for bleeding edge distro and target seems irrelevant to D in general).

Most likely will keep it that way even if upstream layout changes because there is simply no practical reason in overcomplicating it gcc-style. Not right now. Unless see some very complelling arguments of course :)

> /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)

What kind of modules would you put here?

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

I don't think magical addition of /usr/local import paths without explicit user request is good thing.

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

Import distinction from C world distribution model is that with D source-based library distribution is generally more useful than precompiled library + bindings. Mostly because of all extra optimization possibilities and wide template usage.

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

Could you please give a quick overview of how it was supposed to work for now? :)

On 1 Feb 2015 21:50, "Dicebot via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Sunday, 1 February 2015 at 18:58:22 UTC, Iain Buclaw wrote:
>>
>> - It may be a cross compiler.
>> - It may support multiarch/multilib configuration (-m32, -mx32, -m64).
>
>
> AFAIU those are effectively non-existent in D and expected to be handled
with internal version blocks, not file system differentiation during installation.
>
>

These details probably only matter to a package maintainer.  And is more a result of how gcc works, as opposed to intentional design.

>> - The compiler may have been relocated (Think 'DESTDIR=/relocate make
install')
>
>
> Why does it matter?
>

You can move the installation anywhere and it continues to just work, and figure out where everything is located.

>
>> 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)
>
>
> I use simply /usr/include/dlang/<compiler-name> in Arch for now (because
versions are irrelevant for bleeding edge distro and target seems irrelevant to D in general).
>
> Most likely will keep it that way even if upstream layout changes because
there is simply no practical reason in overcomplicating it gcc-style. Not right now. Unless see some very complelling arguments of course :)
>
>> /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)
>
>
> What kind of modules would you put here?
>
>

Everything - as in Druntime and Phobos.  Rational being that they are compiler specific, and so a private location relevant to the compiler seems fitting.

>> 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.
>
>
> I don't think magical addition of /usr/local import paths without
explicit user request is good thing.
>
>
>> 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.
>
>
> Import distinction from C world distribution model is that with D
source-based library distribution is generally more useful than precompiled library + bindings. Mostly because of all extra optimization possibilities and wide template usage.
>
>
>> 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.
>
>
> Could you please give a quick overview of how it was supposed to work for
now? :)

Now or future?

On Sun, 01 Feb 2015 18:58:03 +0000, Iain Buclaw via Digitalmars-d wrote:

unification is great. and seems that nobody else cares anyway, so let it be "GCC-way" then. ;-)

Am Sun, 1 Feb 2015 18:58:03 +0000
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@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?

On 2 February 2015 at 09:53, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Sun, 1 Feb 2015 18:58:03 +0000
> schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@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.

On 2 February 2015 at 13:20, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> On 2 February 2015 at 09:53, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> Am Sun, 1 Feb 2015 18:58:03 +0000
>> schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@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

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

> On 2 February 2015 at 13:20, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
> > On 2 February 2015 at 09:53, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >> Am Sun, 1 Feb 2015 18:58:03 +0000
> >> schrieb Iain Buclaw via Digitalmars-d
> >> <digitalmars-d@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, ...

On 2 February 2015 at 17:22, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Mon, 2 Feb 2015 13:24:09 +0000
> schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:
>
>> On 2 February 2015 at 13:20, Iain Buclaw <ibuclaw@gdcproject.org> wrote:
>> > On 2 February 2015 at 09:53, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> >> Am Sun, 1 Feb 2015 18:58:03 +0000
>> >> schrieb Iain Buclaw via Digitalmars-d
>> >> <digitalmars-d@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.

My attitude to any such changes in general is "I don't care as long as I can easily override it with own patches before packaging gdc".

In practice distro are simply too different to try fitting everything into single pattern. In Arch Linux it is prohibited to package source-only libraries and thus dub is pretty much a necessity. At the same time being a bleeding edge distro it doesn't care for simultaneous support of many compiler versions at once and all that infrastructure can be dropped to keep things KISS.

So, please, whatever you do, keep it easy for packager to override all paths :)