Does D need standard locations?

Dicebot via Digitalmars-d digitalmars-d at puremagic.com
Sun Feb 1 13:48:51 PST 2015


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


More information about the Digitalmars-d mailing list