[Poll] On Linux, what should we commonly use as sub-directory name for D?

[Marco Leise]

Am Wed, 13 Nov 2013 05:35:10 +0100
schrieb "Jesse Phillips" <Jesse.K.Phillips+D at 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