I've seen people use both 'd' and 'dlang' now, so I created a poll. Everyone assembling Linux packages is then free use the results to create a similar experience on all distributions.

http://www.easypolls.net/poll.html?p=52828149e4b06cfb69b97527

-- 
Marco

On Tuesday, 12 November 2013 at 19:50:32 UTC, Marco Leise wrote:
> I've seen people use both 'd' and 'dlang' now, so I created a
> poll. Everyone assembling Linux packages is then free use the
> results to create a similar experience on all distributions.
>
> http://www.easypolls.net/poll.html?p=52828149e4b06cfb69b97527

"dlang" should supersede "d" in all domains, it is a simple matter of ambiguity (I, personally, won't change it whatever poll results are)

On Tuesday, 12 November 2013 at 20:06:31 UTC, Dicebot wrote:
> On Tuesday, 12 November 2013 at 19:50:32 UTC, Marco Leise wrote:
>> I've seen people use both 'd' and 'dlang' now, so I created a
>> poll. Everyone assembling Linux packages is then free use the
>> results to create a similar experience on all distributions.
>>
>> http://www.easypolls.net/poll.html?p=52828149e4b06cfb69b97527
>
> "dlang" should supersede "d" in all domains, it is a simple matter of ambiguity (I, personally, won't change it whatever poll results are)

I don't see why we need such sub-directories. The language doesn't seem important to me.

I also place the source under /usr/src since they actually aren't headers/import files.

Am Wed, 13 Nov 2013 05:35:10 +0100
schrieb "Jesse Phillips" <Jesse.K.Phillips+D@gmail.com>:

> On Tuesday, 12 November 2013 at 20:06:31 UTC, Dicebot wrote:
> > On Tuesday, 12 November 2013 at 19:50:32 UTC, Marco Leise wrote:
> >> I've seen people use both 'd' and 'dlang' now, so I created a poll. Everyone assembling Linux packages is then free use the results to create a similar experience on all distributions.
> >>
> >> http://www.easypolls.net/poll.html?p=52828149e4b06cfb69b97527
> >
> > "dlang" should supersede "d" in all domains, it is a simple matter of ambiguity (I, personally, won't change it whatever poll results are)
> 
> I don't see why we need such sub-directories. The language doesn't seem important to me.
> 
> I also place the source under /usr/src since they actually aren't headers/import files.

Mainly because of ABI incompatibility, which is one reason why
I want to go for parallel installation of different versions
of dmd, ldc and gdc. (For gcc that is already supported at
least on Gentoo.) You are right that for libraries a separate
dlang include dir is not required, but I feel like it would be
clutter to have dmd-2.063, dmd-2.064, ldc-0.12.0 etc. there
and libs still need to be separated by ABI, so they
link and work properly. While you could install them as
libSomething-dmd-2.064.{a,so}, it breaks pragma(lib,...) and
requires you to modify your build scripts to link to the
correct version when switching compilers or D versions.
That's why my preference is:
/usr/lib/{d,dlang}/dmd-2.064/libSomething.a
/usr/lib/{d,dlang}/dmd-2.064/libSomething.so.1.12
/usr/lib/{d,dlang}/dmd-2.065/libSomething.a
/usr/lib/{d,dlang}/dmd-2.065/libSomething.so.1.12
...
In any case there is no point in trying to link an executable
dynamically and have it run on other systems when the lib is
named /usr/lib/libSomething.so.1.12. It could be using dmd,
gdc or ldc ABI and this ABI may have been changed/fixed from
one compiler release to the next.
I'm not even sure we can establish a common scheme like the
above, because at least gcc (and in the future gdc) here has
e.g.: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3 as the "versioned"
library search path and I don't think this is the same on all
Linux distributions?

-- 
Marco

On Tuesday, 12 November 2013 at 19:50:32 UTC, Marco Leise wrote:
> I've seen people use both 'd' and 'dlang' now, so I created a
> poll. Everyone assembling Linux packages is then free use the
> results to create a similar experience on all distributions.
>
> http://www.easypolls.net/poll.html?p=52828149e4b06cfb69b97527

You should have "None above" as an option. Once you do have, that will be my choice, for now, for Phobos certainly.

For users' packages /usr/include/d is my first choice, and that is where I put them. Ah yes, and $HOME/include/d too.

Am Wed, 13 Nov 2013 13:23:17 +0100
schrieb "Dejan Lekic" <dejan.lekic@gmail.com>:

> On Tuesday, 12 November 2013 at 19:50:32 UTC, Marco Leise wrote:
> > I've seen people use both 'd' and 'dlang' now, so I created a poll. Everyone assembling Linux packages is then free use the results to create a similar experience on all distributions.
> >
> > http://www.easypolls.net/poll.html?p=52828149e4b06cfb69b97527
> 
> You should have "None above" as an option. Once you do have, that will be my choice, for now, for Phobos certainly.

I don't want to be limited to one installation of Phobos.
That's why there is no "none" option. It is required to have
e.g.:
/usr/include/dlang/dmd-1.076/druntime
/usr/include/dlang/dmd-2.063/druntime
/usr/include/dlang/dmd-2.064/druntime
/usr/include/dlang/ldc-0.12.0/druntime
and
/usr/lib/dlang/dmd-2.063/phobos.a
/usr/lib/dlang/dmd-2.064/phobos.a

> For users' packages /usr/include/d is my first choice, and that is where I put them. Ah yes, and $HOME/include/d too.

-- 
Marco

On Wednesday, 13 November 2013 at 04:35:12 UTC, Jesse Phillips wrote:
> I don't see why we need such sub-directories. The language doesn't seem important to me.
>
> I also place the source under /usr/src since they actually aren't headers/import files.

Mostly hygiene concerns. One of reasons why C headers are put into /usr/include is that it is default include location and it allows to to directly hit "#include <libheader>" after installing a package, with no explicit paths. Having similar standard location for D library modules is desired but FHS mandates it to be subdirectory of /usr/include (yes, those are import files for D). Making common subdirectory to avoid mixing with C stuff in filesystem is obvious next step.

Am Wed, 13 Nov 2013 14:53:10 +0100
schrieb "Dicebot" <public@dicebot.lv>:

> On Wednesday, 13 November 2013 at 04:35:12 UTC, Jesse Phillips wrote:
> > I don't see why we need such sub-directories. The language doesn't seem important to me.
> >
> > I also place the source under /usr/src since they actually aren't headers/import files.
> 
> Mostly hygiene concerns. One of reasons why C headers are put into /usr/include is that it is default include location and it allows to to directly hit "#include <libheader>" after installing a package, with no explicit paths. Having similar standard location for D library modules is desired but FHS mandates it to be subdirectory of /usr/include (yes, those are import files for D). Making common subdirectory to avoid mixing with C stuff in filesystem is obvious next step.

I guess we could install the D modules right
into /usr/include/dlang, but I know that at least Mono-D would
take too long and consume too much memory if one include path
contained all libraries and there could be package collisions.
So each library will have a subdirectory as well.

-- 
Marco

On 13 November 2013 13:53, Dicebot <public@dicebot.lv> wrote:

> On Wednesday, 13 November 2013 at 04:35:12 UTC, Jesse Phillips wrote:
>
>> I don't see why we need such sub-directories. The language doesn't seem important to me.
>>
>> I also place the source under /usr/src since they actually aren't headers/import files.
>>
>
> Mostly hygiene concerns. One of reasons why C headers are put into /usr/include is that it is default include location and it allows to to directly hit "#include <libheader>" after installing a package, with no explicit paths. Having similar standard location for D library modules is desired but FHS mandates it to be subdirectory of /usr/include (yes, those are import files for D). Making common subdirectory to avoid mixing with C stuff in filesystem is obvious next step.
>

That requires co-operation from upstream compiler projects... distributors are free to have local patches by all means to force the compilers to look in non-standard directories. ;-)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Wednesday, 13 November 2013 at 15:07:57 UTC, Iain Buclaw wrote:
> That requires co-operation from upstream compiler projects... distributors
> are free to have local patches by all means to force the compilers to look
> in non-standard directories. ;-)

Well, you have co-operated with me willingly to help me write those patches some time ago if you remember that ;)