www.digitalmars.com         C & C++   DMDScript  

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

reply Marco Leise <Marco.Leise gmx.de> writes:
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
Nov 12 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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)
Nov 12 2013
next sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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.
Nov 12 2013
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
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
Nov 12 2013
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
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.
Nov 13 2013
next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
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
Nov 13 2013
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
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';
Nov 13 2013
parent "Dicebot" <public dicebot.lv> writes:
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 ;)
Nov 14 2013
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 12/11/13 21:06, Dicebot wrote:

 "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 suggest the opposite -- if "d" is up for grabs, we should grab it and hold on 
to it.  Ambiguity is best overcome by creating a situation where d definitely 
means D. ;-)
Nov 14 2013
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
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.
Nov 13 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
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
Nov 13 2013
parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Wednesday, 13 November 2013 at 13:50:45 UTC, Marco Leise wrote:

 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


You should be clearn that you were asking about where to put 
Phobos, not various D import files (from other D packages).

For Phobos import path, again, I would go for 
/usr/include/d/{dmd*|ldc*|gdc*}

For the libraries, I also follow the same approach ArchLinux 
packages do. Honestly, no need for /usr/lib/dlang/blabla . Keep 
them all in the /usr/lib or /usr/lib{32|64} depending on distro...
Nov 14 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 14 Nov 2013 19:11:17 +0100
schrieb "Dejan Lekic" <dejan.lekic gmail.com>:


 On Wednesday, 13 November 2013 at 13:50:45 UTC, Marco Leise wrote:

 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


 
 You should be clearn that you were asking about where to put 
 Phobos, not various D import files (from other D packages).


Both actually. This was just an example with no bike-shedding
potential.


 For Phobos import path, again, I would go for 
 /usr/include/d/{dmd*|ldc*|gdc*}
 
 For the libraries, I also follow the same approach ArchLinux 
 packages do. Honestly, no need for /usr/lib/dlang/blabla . Keep 
 them all in the /usr/lib or /usr/lib{32|64} depending on distro...


In fact there is a need for it as soon as you install them once
for each compiler. And that's where I want to go.
Alternatively suffixes could be used, but that makes it more
difficult to find the correct library name. So I went for
sub-directories.

-- 
Marco
Nov 14 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 14 Nov 2013 20:02:46 +0100
schrieb Marco Leise <Marco.Leise gmx.de>:


 Am Thu, 14 Nov 2013 19:11:17 +0100
 schrieb "Dejan Lekic" <dejan.lekic gmail.com>:
 

 On Wednesday, 13 November 2013 at 13:50:45 UTC, Marco Leise wrote:

 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


 
 You should be clearn that you were asking about where to put 
 Phobos, not various D import files (from other D packages).


 
 Both actually. This was just an example with no bike-shedding
 potential.
 

 For Phobos import path, again, I would go for 
 /usr/include/d/{dmd*|ldc*|gdc*}
 
 For the libraries, I also follow the same approach ArchLinux 
 packages do. Honestly, no need for /usr/lib/dlang/blabla . Keep 
 them all in the /usr/lib or /usr/lib{32|64} depending on distro...


 
 In fact there is a need for it as soon as you install them once
 for each compiler. And that's where I want to go.
 Alternatively suffixes could be used, but that makes it more
 difficult to find the correct library name. So I went for
 sub-directories.
 


AFAIK you can't put shared libraries into a different folder.
The runtime linker must be able to find the libraries so the folders
have to be registered in ld.so.conf. But ld 'virtually merges' all
directories so you still can't have libraries with the same name &
version in different folders. There are some tricks (rpath,
LD_LIBRARY_PATH) but this won't work well in a large scale scenario.

In the end all D compilers have to produce ABI compatible
shared libraries. The runtime implementation may be different, but the
ABI has to match. Unfortunately ABI compatibility is still in a distant
future but there's no other way to solve the library issue.
Nov 14 2013
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On Nov 14, 2013 8:40 PM, "Johannes Pfau" <nospam example.com> wrote:

 Am Thu, 14 Nov 2013 20:02:46 +0100
 schrieb Marco Leise <Marco.Leise gmx.de>:


 Am Thu, 14 Nov 2013 19:11:17 +0100
 schrieb "Dejan Lekic" <dejan.lekic gmail.com>:


 On Wednesday, 13 November 2013 at 13:50:45 UTC, Marco Leise wrote:

 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


 You should be clearn that you were asking about where to put
 Phobos, not various D import files (from other D packages).


 Both actually. This was just an example with no bike-shedding
 potential.


 For Phobos import path, again, I would go for
 /usr/include/d/{dmd*|ldc*|gdc*}

 For the libraries, I also follow the same approach ArchLinux
 packages do. Honestly, no need for /usr/lib/dlang/blabla . Keep
 them all in the /usr/lib or /usr/lib{32|64} depending on distro...


 In fact there is a need for it as soon as you install them once
 for each compiler. And that's where I want to go.
 Alternatively suffixes could be used, but that makes it more
 difficult to find the correct library name. So I went for
 sub-directories.


 AFAIK you can't put shared libraries into a different folder.
 The runtime linker must be able to find the libraries so the folders
 have to be registered in ld.so.conf. But ld 'virtually merges' all
 directories so you still can't have libraries with the same name &
 version in different folders. There are some tricks (rpath,
 LD_LIBRARY_PATH) but this won't work well in a large scale scenario.

 In the end all D compilers have to produce ABI compatible
 shared libraries. The runtime implementation may be different, but the
 ABI has to match. Unfortunately ABI compatibility is still in a distant
 future but there's no other way to solve the library issue.


And you can make a start in the direction of ABI compatibility by dropping
the D calling convention.  :-)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Nov 14 2013
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 14 Nov 2013 21:35:22 +0100
schrieb Johannes Pfau <nospam example.com>:


 AFAIK you can't put shared libraries into a different folder.
 The runtime linker must be able to find the libraries so the folders
 have to be registered in ld.so.conf. But ld 'virtually merges' all
 directories so you still can't have libraries with the same name &
 version in different folders. There are some tricks (rpath,
 LD_LIBRARY_PATH) but this won't work well in a large scale scenario.


That explains why Haskell's Cabal is installing libraries with
compiler AND library version in the file name :-/
 

 In the end all D compilers have to produce ABI compatible
 shared libraries. The runtime implementation may be different, but the
 ABI has to match. Unfortunately ABI compatibility is still in a distant
 future but there's no other way to solve the library issue.


That would be helpful. In the meantime I'll read up on how
dynamic linking works and what options I have.

-- 
Marco
Nov 14 2013
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 15 Nov 2013 00:03:42 +0100
schrieb Marco Leise <Marco.Leise gmx.de>:


 Am Thu, 14 Nov 2013 21:35:22 +0100
 schrieb Johannes Pfau <nospam example.com>:
 

 AFAIK you can't put shared libraries into a different folder.
 The runtime linker must be able to find the libraries so the folders
 have to be registered in ld.so.conf. But ld 'virtually merges' all
 directories so you still can't have libraries with the same name &
 version in different folders. There are some tricks (rpath,
 LD_LIBRARY_PATH) but this won't work well in a large scale scenario.


 
 That explains why Haskell's Cabal is installing libraries with
 compiler AND library version in the file name :-/


That doesn't read too bad:
http://en.wikipedia.org/wiki/Rpath#GNU_ld.so
So -rpath basically just hints at the library location.
CMake has more or less direct support for it:
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")

The other option would be to install a symlink foo.so into the
compiler specific lib directory that links
to /usr/lib/foo-dmd.so.X.Y that has an soname of "foo.so.X".
But I feel that would confuse the pants off of people.

-- 
Marco
Nov 14 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 15 Nov 2013 01:01:34 +0100
schrieb Marco Leise <Marco.Leise gmx.de>:


 Am Fri, 15 Nov 2013 00:03:42 +0100
 schrieb Marco Leise <Marco.Leise gmx.de>:
 

 Am Thu, 14 Nov 2013 21:35:22 +0100
 schrieb Johannes Pfau <nospam example.com>:
 

 AFAIK you can't put shared libraries into a different folder.
 The runtime linker must be able to find the libraries so the
 folders have to be registered in ld.so.conf. But ld 'virtually
 merges' all directories so you still can't have libraries with
 the same name & version in different folders. There are some
 tricks (rpath, LD_LIBRARY_PATH) but this won't work well in a
 large scale scenario.


 
 That explains why Haskell's Cabal is installing libraries with
 compiler AND library version in the file name :-/


 
 That doesn't read too bad:
 http://en.wikipedia.org/wiki/Rpath#GNU_ld.so
 So -rpath basically just hints at the library location.
 CMake has more or less direct support for it:
 SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
 
 The other option would be to install a symlink foo.so into the
 compiler specific lib directory that links
 to /usr/lib/foo-dmd.so.X.Y that has an soname of "foo.so.X".
 But I feel that would confuse the pants off of people.
 


The linux distributions will have to agree with this path schemes
though. It's probably more a political problem, but still.

For example in debian using rpath is discouraged
https://wiki.debian.org/RpathIssue

There's also another bad consequence of missing binary compatibility: If
you have app A compiled with LDC and app B compiled with GDC and both
app A and B depend on vibeD, mustached, dyaml then you'll have too keep
copies of all those libraries for gdc and ldc. I guess most linux
distributions will just choose one compiler and then compile everything
with this compiler. (Probably not DMD because of OSS reasons)

But I don't have a good or quick solution for this issue so I certainly
won't complain about any working solution ;-)
Nov 15 2013
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 15 Nov 2013 20:34:25 +0100
schrieb Johannes Pfau <nospam example.com>:


 Am Fri, 15 Nov 2013 01:01:34 +0100
 schrieb Marco Leise <Marco.Leise gmx.de>:
 

 Am Fri, 15 Nov 2013 00:03:42 +0100
 schrieb Marco Leise <Marco.Leise gmx.de>:
 

 Am Thu, 14 Nov 2013 21:35:22 +0100
 schrieb Johannes Pfau <nospam example.com>:
 

 AFAIK you can't put shared libraries into a different folder.
 The runtime linker must be able to find the libraries so the
 folders have to be registered in ld.so.conf. But ld 'virtually
 merges' all directories so you still can't have libraries with
 the same name & version in different folders. There are some
 tricks (rpath, LD_LIBRARY_PATH) but this won't work well in a
 large scale scenario.


 
 That explains why Haskell's Cabal is installing libraries with
 compiler AND library version in the file name :-/


 
 That doesn't read too bad:
 http://en.wikipedia.org/wiki/Rpath#GNU_ld.so
 So -rpath basically just hints at the library location.
 CMake has more or less direct support for it:
 SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
 
 The other option would be to install a symlink foo.so into the
 compiler specific lib directory that links
 to /usr/lib/foo-dmd.so.X.Y that has an soname of "foo.so.X".
 But I feel that would confuse the pants off of people.
 


 
 The linux distributions will have to agree with this path schemes
 though. It's probably more a political problem, but still.
 
 For example in debian using rpath is discouraged
 https://wiki.debian.org/RpathIssue
 
 There's also another bad consequence of missing binary compatibility: If
 you have app A compiled with LDC and app B compiled with GDC and both
 app A and B depend on vibeD, mustached, dyaml then you'll have too keep
 copies of all those libraries for gdc and ldc.


Yes, making this possible is the reason I'm going through all
the trouble in the first place. Currently it is difficult to
keep these copies around and up to date if you want to test
different compilers and D versions with your code.
This should be handled by the package manager and some global
and per package variables that list the D versions to use.


 I guess most linux distributions will just choose one compiler and then
 compile everything with this compiler. (Probably not DMD because of OSS
 reasons)


Sure, but different distributions exist because some people
have other ideas of Linux. E.g. Gentoo has always been about
freedom of choice. And for us as developers it is always good
to be able to easily compile code with any of the D compilers,
including library dependencies. If you only had GDC or LDC you
couldn't test your D program with the upcoming beta of DMD.
Well, you could download it, but then you need to recompile
all D libraries that you need with DMD and make sure you don't
mess up the existing LDC/GDC installation of those libs.


 But I don't have a good or quick solution for this issue so I certainly
 won't complain about any working solution ;-)


That's what I wanted to hear!

-- 
Marco
Nov 15 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 12/11/13 20:50, 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.


I'm not sure a poll is the appropriate way to decide this, to be honest.  The 
decision should be based on something very simple -- is there anything else out 
there that is using 'd' as subdirectory name?

If there's no precedent of some other project using 'd', why not stake the
claim?
Nov 14 2013
prev sibling parent reply Chris Piker <fake fakeU.edu> writes:
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


Has this issued been settled?  We are using the dmd compiler on 
CentOS 6.  I have a custom plplot.d file that I want to put 
somewhere under our shared /usr/local for our programmers to use. 
  If I want to follow some sort of precedent then it looks like my 
choices are:

   /usr/local/include/dmd   (similar to dmd rpm)
   /usr/local/include
   /usr/local/include/d
   /usr/local/include/dlang
   /usr/local/src
   /usr/local/src/d
   /usr/local/src/dlang

I personally prefer:

   /usr/local/src/d

but would like to go with some sort of convention if one is 
starting to gel.

Please don't say use dub and leave it up to each individual 
developer.  I haven't been able to get dub to work on CentOS 6, 
and just getting D in use here is enough of an effort without 
introducing package management tools.
Nov 11 2015
next sibling parent reply Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
On Wednesday, 11 November 2015 at 17:24:19 UTC, Chris Piker 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


 Has this issued been settled?  We are using the dmd compiler on 
 CentOS 6.  I have a custom plplot.d file that I want to put 
 somewhere under our shared /usr/local for our programmers to 
 use.
  If I want to follow some sort of precedent then it looks like 
 my choices are:

   /usr/local/include/dmd   (similar to dmd rpm)
   /usr/local/include
   /usr/local/include/d
   /usr/local/include/dlang
   /usr/local/src
   /usr/local/src/d
   /usr/local/src/dlang

 I personally prefer:

   /usr/local/src/d

 but would like to go with some sort of convention if one is 
 starting to gel.

 Please don't say use dub and leave it up to each individual 
 developer.  I haven't been able to get dub to work on CentOS 6, 
 and just getting D in use here is enough of an effort without 
 introducing package management tools.


I'm interested in this topic, too. Has there been a conclusion as 
to distributions should install includes and libraries of 
different compilers (and versions), which sonames to use, etc?
Nov 12 2015
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 12 Nov 2015 10:26:54 +0000
schrieb Marc Sch=C3=BCtz <schuetzm gmx.net>:


 I'm interested in this topic, too. Has there been a conclusion as=20
 to distributions should install includes and libraries of=20
 different compilers (and versions), which sonames to use, etc?


The shared library topic was too hot back then and DMD I think
is still the only compiler which does shared linking out of
the box in a default installation. If you ask about only
Phobos, I would just use the soname provided by upstream:
  libphobos2.so.0.69.1
  libphobos2.so.0.69   -> libphobos2.so.0.69.1
  libphobos2.so        -> libphobos2.so.0.69.1
(The convention for the first symlink may differ per
distribution). These files should be installed into your
system's shared library lookup path, so that dynamically linked
executables can be run on other systems. For example you could
compile a program on your machine and ssh copy it to a remote
server running in a low memory VM where compilation would be
impossible. If that use case works, you are doing it right. ;)

As for additional libraries, you are in trouble. Not only is
it common to have 32-bit+64-bit libraries, but we also have
ABI differences between three popular D compilers and
potentially each new release of Dlang. So if you ask where to
put libraries I'd say somewhere, where they are separated by
architecture, compiler and compiler version. While this scheme
works for Gentoo, I had to bend the rules quite liberally to
make it happen and these packages have no chance of getting
into the main tree.

The alternative is to always use one compiler (e.g. DMD) and
update all libraries in sync with a DMD update. Then you can
install these libraries to the standard path as well. This is
practically what is done in the C/C++ world. ABI breakages are
far and in-between there but do happen like just now with the
change to use a namespace prefix for the mangling of "string".

(For includes see previous post and discussion.)

--=20
Marco
Nov 15 2015
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 16 Nov 2015 8:15 am, "Marco Leise via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 Am Thu, 12 Nov 2015 10:26:54 +0000
 schrieb Marc Sch=C3=BCtz <schuetzm gmx.net>:


 I'm interested in this topic, too. Has there been a conclusion as
 to distributions should install includes and libraries of
 different compilers (and versions), which sonames to use, etc?


 The shared library topic was too hot back then and DMD I think
 is still the only compiler which does shared linking out of
 the box in a default installation. If you ask about only
 Phobos, I would just use the soname provided by upstream:
   libphobos2.so.0.69.1
   libphobos2.so.0.69   -> libphobos2.so.0.69.1
   libphobos2.so        -> libphobos2.so.0.69.1


Another thing to note would be that gdc names the library libgphobos2 to
avoid conflict.  I suspect ldc does the same, or if it doesn't, would have
to be patched locally to.


 (The convention for the first symlink may differ per
 distribution). These files should be installed into your
 system's shared library lookup path, so that dynamically linked
 executables can be run on other systems. For example you could
 compile a program on your machine and ssh copy it to a remote
 server running in a low memory VM where compilation would be
 impossible. If that use case works, you are doing it right. ;)

 As for additional libraries, you are in trouble. Not only is
 it common to have 32-bit+64-bit libraries, but we also have
 ABI differences between three popular D compilers and
 potentially each new release of Dlang. So if you ask where to
 put libraries I'd say somewhere, where they are separated by
 architecture, compiler and compiler version. While this scheme
 works for Gentoo, I had to bend the rules quite liberally to
 make it happen and these packages have no chance of getting
 into the main tree.

 The alternative is to always use one compiler (e.g. DMD) and
 update all libraries in sync with a DMD update. Then you can
 install these libraries to the standard path as well. This is
 practically what is done in the C/C++ world. ABI breakages are
 far and in-between there but do happen like just now with the
 change to use a namespace prefix for the mangling of "string".


There should be ways to catch ABI changes in the build or test process.
Maybe I'm misremembering something though. :-)

There should be a degree of ABI compatibility between releases for plain
static functions - assuming that we add no more properties to the
language.  That leaves what breaks the most in moving to a new version are
template instantiations, no?
Nov 15 2015
parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Mon, 16 Nov 2015 08:49:57 +0100
schrieb Iain Buclaw via Digitalmars-d
<digitalmars-d puremagic.com>:


 There should be ways to catch ABI changes in the build or test process.
 Maybe I'm misremembering something though. :-)
 
 There should be a degree of ABI compatibility between releases for plain
 static functions - assuming that we add no more properties to the
 language.  That leaves what breaks the most in moving to a new version are
 template instantiations, no?


Frankly I have no idea what level of testing is in place. :D
To be practical for package maintainers, we would need some
higher level common D ABI versioning scheme that includes
Phobos. Then I could start grouping libraries by architecture
and this ABI version instead of by compiler/FE version. But
let's take baby steps here and first get DMD to use DWARF EH.
Once we can dynamically link DMD<->GDC, DMD<->LDC, we can
think about a stable Dlang ABI in terms of EH, function
mangling, Phobos etc.
I can easily see Phobos being split out of the DMD release
cycle by then, with both loosely depending on each other.

-- 
Marco
Nov 16 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 16 November 2015 at 09:30, Marco Leise via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 Am Mon, 16 Nov 2015 08:49:57 +0100
 schrieb Iain Buclaw via Digitalmars-d
 <digitalmars-d puremagic.com>:


 There should be ways to catch ABI changes in the build or test process.
 Maybe I'm misremembering something though. :-)

 There should be a degree of ABI compatibility between releases for plain
 static functions - assuming that we add no more properties to the
 language.  That leaves what breaks the most in moving to a new version


 are

 template instantiations, no?


 Frankly I have no idea what level of testing is in place. :D
 To be practical for package maintainers, we would need some
 higher level common D ABI versioning scheme that includes
 Phobos. Then I could start grouping libraries by architecture
 and this ABI version instead of by compiler/FE version. But
 let's take baby steps here and first get DMD to use DWARF EH.
 Once we can dynamically link DMD<->GDC, DMD<->LDC, we can
 think about a stable Dlang ABI in terms of EH, function
 mangling, Phobos etc.


A good litmus test would be to take the C++ ABI tests in the D2 testsuite,
and convert the C++ sources to D.  Build one with DMD and the other with
GDC.  If something segfaults or goes wrong at runtime, then raise a bug
about how DMD doesn't pass parameters correctly. ;-)

Besides, I'd worry more about how DMD keeps changing the names of runtime
hooks to be able to do things GDC has done for years.  With Dwarf EH thrown
into the mix, there's now three functions that handle throwing objects (GDC
still only has one).  Not cool man!
Nov 16 2015
prev sibling parent reply Marco Leise <Marco.Leise gmx.de> writes:
Am Wed, 11 Nov 2015 17:24:18 +0000
schrieb Chris Piker <fake fakeU.edu>:


 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


 
 Has this issued been settled?  We are using the dmd compiler on 
 CentOS 6.  I have a custom plplot.d file that I want to put 
 somewhere under our shared /usr/local for our programmers to use. 
   If I want to follow some sort of precedent then it looks like my 
 choices are:
 
    /usr/local/include/dmd   (similar to dmd rpm)
    /usr/local/include
    /usr/local/include/d
    /usr/local/include/dlang
    /usr/local/src
    /usr/local/src/d
    /usr/local/src/dlang
 
 I personally prefer:
 
    /usr/local/src/d
 
 but would like to go with some sort of convention if one is 
 starting to gel.


By secret ballot vote in this poll options with "d" in it lost
1:2 to "dlang". As far as I know this was the only real effort
to unify directory names across Linux distributions and at
least two package maintainers (Dicebot for Arch Linux and me
on Gentoo) have used the input from the following discussion
to decide on an import path for the currently active system DMD
compiler:

  /usr/include/dlang/dmd

This was after the official DMD package build script
for .rpm/.deb have been created and "D" was renamed to
"Dlang", so the discussion had no influence on their layout.

As far as /usr/local/src goes, I've never seen anything but OS
sources (i.e. Linux kernel) being installed to /usr/src
and /usr/local is conventionally used like /usr, but for
additional local files that are not covered by the generic OS
installation:
https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s3-filesystem-usr-local.html

As for installing additional Dlang library imports, I advise
to use one subdirectory in /usr/include/dlang for each package
and "parallel version". What I mean by that is that many real
packages change their API over the years, sometimes so
radically that some packages stick with previous versions. One
such example is Gtk, with GIMP still using Gtk 2 and Gnome
being linked against Gtk 3. In such cases you want be able to
include either gtk2 or gtk3. Now if you look at GtkD you see
this reflected in different import paths, namely gtkd-2 and
gtkd-3. Both contain common module paths like gtkc/cairo.d
that would overwrite each other if not put under different
parent directories. And once you have

  /usr/include/dlang/dmd
  /usr/include/dlang/ldc
  /usr/include/dlang/gtkd-2
  /usr/include/dlang/gtkd-3

it makes sense to handle other libraries the same way.

In your specific case you may be able to get away with a
single flat import path for everything by allowing only one
version of dmd, GtkD etc., but other distributions will not be
able to follow this scheme. I hope this helps you in your
decision making.

-- 
Marco
Nov 15 2015
parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 16 Nov 2015 7:35 am, "Marco Leise via Digitalmars-d" <
digitalmars-d puremagic.com> wrote:

 Am Wed, 11 Nov 2015 17:24:18 +0000
 schrieb Chris Piker <fake fakeU.edu>:


 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


 Has this issued been settled?  We are using the dmd compiler on
 CentOS 6.  I have a custom plplot.d file that I want to put
 somewhere under our shared /usr/local for our programmers to use.
   If I want to follow some sort of precedent then it looks like my
 choices are:

    /usr/local/include/dmd   (similar to dmd rpm)
    /usr/local/include
    /usr/local/include/d
    /usr/local/include/dlang
    /usr/local/src
    /usr/local/src/d
    /usr/local/src/dlang

 I personally prefer:

    /usr/local/src/d

 but would like to go with some sort of convention if one is
 starting to gel.


 By secret ballot vote in this poll options with "d" in it lost
 1:2 to "dlang". As far as I know this was the only real effort
 to unify directory names across Linux distributions and at
 least two package maintainers (Dicebot for Arch Linux and me
 on Gentoo) have used the input from the following discussion
 to decide on an import path for the currently active system DMD
 compiler:

   /usr/include/dlang/dmd

 This was after the official DMD package build script
 for .rpm/.deb have been created and "D" was renamed to
 "Dlang", so the discussion had no influence on their layout.

 As far as /usr/local/src goes, I've never seen anything but OS
 sources (i.e. Linux kernel) being installed to /usr/src
 and /usr/local is conventionally used like /usr, but for
 additional local files that are not covered by the generic OS
 installation:


https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s3-filesystem-usr-local.html

 As for installing additional Dlang library imports, I advise
 to use one subdirectory in /usr/include/dlang for each package
 and "parallel version". What I mean by that is that many real
 packages change their API over the years, sometimes so
 radically that some packages stick with previous versions. One
 such example is Gtk, with GIMP still using Gtk 2 and Gnome
 being linked against Gtk 3. In such cases you want be able to
 include either gtk2 or gtk3. Now if you look at GtkD you see
 this reflected in different import paths, namely gtkd-2 and
 gtkd-3. Both contain common module paths like gtkc/cairo.d
 that would overwrite each other if not put under different
 parent directories. And once you have

   /usr/include/dlang/dmd
   /usr/include/dlang/ldc
   /usr/include/dlang/gtkd-2
   /usr/include/dlang/gtkd-3


GDC uses a more private location to stash runtime and phobos modules
specifically tied to the compiler.  And though the postfix defaults to `d`,
distributors can change this.
Nov 15 2015