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.

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?

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

Am Thu, 12 Nov 2015 10:26:54 +0000
schrieb Marc Schütz <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
(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.)

-- 
Marco

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.

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ütz <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?

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

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!