Does D need standard locations?

[Iain Buclaw via Digitalmars-d]

On 1 Feb 2015 21:50, "Dicebot via Digitalmars-d" <
digitalmars-d at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20150201/794a48fd/attachment.html>