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

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

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

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?

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.

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

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

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

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

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