<p dir="ltr"><br>
On 1 Feb 2015 21:50, "Dicebot via Digitalmars-d" <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br>
><br>
> On Sunday, 1 February 2015 at 18:58:22 UTC, Iain Buclaw wrote:<br>
>><br>
>> - It may be a cross compiler.<br>
>> - It may support multiarch/multilib configuration (-m32, -mx32, -m64).<br>
><br>
><br>
> AFAIU those are effectively non-existent in D and expected to be handled with internal version blocks, not file system differentiation during installation.<br>
><br>
></p>
<p dir="ltr">These details probably only matter to a package maintainer.  And is more a result of how gcc works, as opposed to intentional design.</p>
<p dir="ltr">>> - The compiler may have been relocated (Think 'DESTDIR=/relocate make install')<br>
><br>
><br>
> Why does it matter?<br>
></p>
<p dir="ltr">You can move the installation anywhere and it continues to just work, and figure out where everything is located.</p>
<p dir="ltr">><br>
>> Traditionally, we've gone for the following two locations to look for<br>
>> D sources (ignoring cross compilers for the moment).<br>
>><br>
>> /usr/include/d/$(version)<br>
>> /usr/include/d/$(version)/$(target)/$(multilib)<br>
><br>
><br>
> 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).<br>
><br>
> 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 :)<br>
><br>
>> /usr/lib/gcc/$(target)/$(version)/include/d/$(multilib)<br>
><br>
><br>
> What kind of modules would you put here?<br>
><br>
></p>
<p dir="ltr">Everything - as in Druntime and Phobos.  Rational being that they are compiler specific, and so a private location relevant to the compiler seems fitting.</p>
<p dir="ltr">>> Suddenly, you can install a D source file in any of the<br>
>> system, local, or target include directories, and it will be<br>
>> automatically picked up by the compiler.<br>
><br>
><br>
> I don't think magical addition of /usr/local import paths without explicit user request is good thing.<br>
><br>
><br>
>> However, this may not be a good thing.  The way we are going with<br>
>> dealing with D libraries - it looks like the only way is Dub and<br>
>> introducing this *now* brings nothing to the table.<br>
><br>
><br>
> 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.<br>
><br>
><br>
>> Regardless, this is much better for GDC, and allows for hundreds of<br>
>> deletions in scripts to follow, not to mention offloading the logic of<br>
>> *where* things should be installed back to GCC.  So for the time<br>
>> being, we say 'Hello' to the traditional idioms of last century, and<br>
>> see what abuse scales from there.<br>
><br>
><br>
> Could you please give a quick overview of how it was supposed to work for now? :)</p>
<p dir="ltr">Now or future?</p>