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

[Marco Leise via Digitalmars-d]

Am Mon, 16 Nov 2015 08:49:57 +0100
schrieb Iain Buclaw via Digitalmars-d
:

> 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

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

[Iain Buclaw via Digitalmars-d]

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
> :
>
> > 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!

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

[Marco Leise via Digitalmars-d]

Am Wed, 11 Nov 2015 17:24:18 +
schrieb Chris Piker :

> 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

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

[Marco Leise via Digitalmars-d]

Am Thu, 12 Nov 2015 10:26:54 +
schrieb Marc Schütz :

> 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

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

[Iain Buclaw via Digitalmars-d]

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 +
> schrieb Chris Piker :
>
> > 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.

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

[Iain Buclaw via Digitalmars-d]

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 +
> schrieb Marc Schütz :
>
> > 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?

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

[Marc Schütz via Digitalmars-d]

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?

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

[Chris Piker via Digitalmars-d]

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.

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

[Johannes Pfau]

Am Fri, 15 Nov 2013 01:01:34 +0100
schrieb Marco Leise marco.le...@gmx.de:

 Am Fri, 15 Nov 2013 00:03:42 +0100
 schrieb Marco Leise marco.le...@gmx.de:
 
  Am Thu, 14 Nov 2013 21:35:22 +0100
  schrieb Johannes Pfau nos...@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 ;-)

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

[Marco Leise]

Am Fri, 15 Nov 2013 20:34:25 +0100
schrieb Johannes Pfau nos...@example.com:

 Am Fri, 15 Nov 2013 01:01:34 +0100
 schrieb Marco Leise marco.le...@gmx.de:
 
  Am Fri, 15 Nov 2013 00:03:42 +0100
  schrieb Marco Leise marco.le...@gmx.de:
  
   Am Thu, 14 Nov 2013 21:35:22 +0100
   schrieb Johannes Pfau nos...@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

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

[Dicebot]

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 ;)

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

[Joseph Rushton Wakeling]

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. ;-)

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

[Dejan Lekic]

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.le...@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...

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

[Marco Leise]

Am Thu, 14 Nov 2013 19:11:17 +0100
schrieb Dejan Lekic dejan.le...@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

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

[Joseph Rushton Wakeling]

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?

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

[Johannes Pfau]

Am Thu, 14 Nov 2013 20:02:46 +0100
schrieb Marco Leise marco.le...@gmx.de:

 Am Thu, 14 Nov 2013 19:11:17 +0100
 schrieb Dejan Lekic dejan.le...@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.

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

[Iain Buclaw]

On Nov 14, 2013 8:40 PM, Johannes Pfau nos...@example.com wrote:

 Am Thu, 14 Nov 2013 20:02:46 +0100
 schrieb Marco Leise marco.le...@gmx.de:

  Am Thu, 14 Nov 2013 19:11:17 +0100
  schrieb Dejan Lekic dejan.le...@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';

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

[Marco Leise]

Am Thu, 14 Nov 2013 21:35:22 +0100
schrieb Johannes Pfau nos...@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

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

[Marco Leise]

Am Fri, 15 Nov 2013 00:03:42 +0100
schrieb Marco Leise marco.le...@gmx.de:

 Am Thu, 14 Nov 2013 21:35:22 +0100
 schrieb Johannes Pfau nos...@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

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

[Dejan Lekic]

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.

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

[Dicebot]

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.

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

[Marco Leise]

Am Wed, 13 Nov 2013 13:23:17 +0100
schrieb Dejan Lekic dejan.le...@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

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

[Marco Leise]

Am Wed, 13 Nov 2013 14:53:10 +0100
schrieb Dicebot pub...@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

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

[Iain Buclaw]

On 13 November 2013 13:53, Dicebot pub...@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';

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

[Marco Leise]

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

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

[Dicebot]

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)

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

[Jesse Phillips]

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.