www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Debian packages for D libraries

reply Thomas Koch <thomas koch.ro> writes:
Hi,

I already asked on D.learn without much response[1]. I'm just starting to 
learn D (coming from Pascal, PHP, Java) and it feels hard to get started 
without a single D library packaged in Debian. So I thought we could start 
getting the libraries from the google code apt repo into official Debian[2].

[1] "Packaging D libraries, cross compiler compatibility"
[2] http://code.google.com/p/d-apt/issues/detail?id=1

The open issues seem to be:

- Where do header files go? see thread in this group: "I think we need to 
standardize where D headers are to be installed"

- Where do shared libraries go?

- Does it matter which compiler produced a shared library? If so, how to 
deal with it? It would be possible to compile d libraries when the user 
installs them for every D compiler present on the system. A similar thing is 
done for emacs lisp files.

- Yes, dmd could perfectly be put in Debian non-free. GDC and DMD should 
both provide the virtual package name "d-compiler". Debians alternatives 
system can then be used to manage a symbolic link called "d-compiler"(?) to 
point to either dmd, gdc or anything else.

I don't think that some random apt repo on google code is a proper 
alternative to having D libraries in official Debian. I wouldn't like to add 
the gpg key of a random site to my apt keyring.

I'm a Debian Maintainer, still unexperienced with C/C++/D library stuff but 
maybe I could help a bit.

Best regards, Thomas Koch
Oct 03 2012
next sibling parent "Rob T" <rob ucora.com> writes:
There's a Debian repository
https://code.google.com/p/d-apt/wiki/APT_Repository

You can also manually insall DMD deb package on Debian from this 
site
http://dlang.org/download.html

The GDC versions shipped with Debian are out of date. I installed 
from git repository but it is not fun to do. GDC has some 
advantages over DMD on Linux as it uses lastest gcc and has 
similar command line interface (it also has a command line 
version matching DMD). There's an effort underway to merge GDC 
with GCC 4.8, I sure hope that works out in time.

Search these forums for GDC and you'll find some helpful links 
and advice eventually.


--rt
Oct 03 2012
prev sibling next sibling parent "Rob T" <rob ucora.com> writes:
Sorry, I read your question completely wrong. I need another cup 
of coffee ...


On Wednesday, 3 October 2012 at 16:42:46 UTC, Rob T wrote:
 There's a Debian repository
 https://code.google.com/p/d-apt/wiki/APT_Repository

 You can also manually insall DMD deb package on Debian from 
 this site
 http://dlang.org/download.html

 The GDC versions shipped with Debian are out of date. I 
 installed from git repository but it is not fun to do. GDC has 
 some advantages over DMD on Linux as it uses lastest gcc and 
 has similar command line interface (it also has a command line 
 version matching DMD). There's an effort underway to merge GDC 
 with GCC 4.8, I sure hope that works out in time.

 Search these forums for GDC and you'll find some helpful links 
 and advice eventually.


 --rt

Oct 03 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Oct 03, 2012 at 04:57:24PM +0200, Thomas Koch wrote:
[...]
 I already asked on D.learn without much response[1]. I'm just starting
 to learn D (coming from Pascal, PHP, Java) and it feels hard to get
 started without a single D library packaged in Debian. So I thought we
 could start getting the libraries from the google code apt repo into
 official Debian[2].

The standard library should be already packaged. But yeah, it would be nice to have other libraries available. [...]
 The open issues seem to be:
 
 - Where do header files go? see thread in this group: "I think we need
 to standardize where D headers are to be installed"

Until that's decided, I think /usr/include/d is a good place to start. So we'd have /usr/include/d/core/, /usr/include/d/std/, etc.. To support incompatible library versions, we can have different druntime/Phobos versions in subdirs (e.g. /usr/include/d/2.060/core/, /usr/include/d/2.060/std/, etc.) and use the alternatives system to symlink the standard headers into /usr/include/d/. Different compiler releases can then look in specific version subdirs if they require a specific version of Phobos.
 - Where do shared libraries go?

Right now Phobos doesn't even produce shared libs. I think it should be safe to put them in /usr/lib, because D has its own name manglings and we *are* supposed to be able to link C/C++ to D directly anyway.
 - Does it matter which compiler produced a shared library? If so, how
 to deal with it? It would be possible to compile d libraries when the
 user installs them for every D compiler present on the system. A
 similar thing is done for emacs lisp files.

Libraries produced by gdc, AFAIK, should be binary compatible with other C/C++ code compiled by gcc and derivatives. I'm not sure about cross compatibility with dmd, though.
 - Yes, dmd could perfectly be put in Debian non-free. GDC and DMD
 should both provide the virtual package name "d-compiler". Debians
 alternatives system can then be used to manage a symbolic link called
 "d-compiler"(?) to point to either dmd, gdc or anything else.

I'm kinda on the fence about this one, mainly because dmd and gdc have different command-line syntaxes. Yes gdc has a compatibility mode, but that's not its "native" syntax. Ideally the symlink should point to executables that have more-or-less the same command-line syntax. It would suck if build scripts start failing just because you updated the symlink to a different compiler.
 I don't think that some random apt repo on google code is a proper
 alternative to having D libraries in official Debian. I wouldn't like
 to add the gpg key of a random site to my apt keyring.

 I'm a Debian Maintainer, still unexperienced with C/C++/D library
 stuff but maybe I could help a bit.

I'm willing to sponsor uploads if somebody has the time to work with the packaging. :) T -- Two wrongs don't make a right; but three rights do make a left...
Oct 03 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Wednesday, 3 October 2012 at 14:57:16 UTC, Thomas Koch wrote:
 - Does it matter which compiler produced a shared library?

In short, yes, and it is unlikely to change in the near future as we don't even have a comprehensive D ABI specification yet – what is e.g. completely unspecified are nested functions –, and DMD does not implement the System V x86_64 ABI correctly either (LDC gets ordinary functions right, but varargs are subtly broken). David
Oct 03 2012
prev sibling parent "Rob T" <rob ucora.com> writes:
On Wednesday, 3 October 2012 at 17:18:44 UTC, H. S. Teoh wrote:
 I'm kinda on the fence about this one, mainly because dmd and 
 gdc have
 different command-line syntaxes. Yes gdc has a compatibility 
 mode, but
 that's not its "native" syntax. Ideally the symlink should 
 point to
 executables that have more-or-less the same command-line 
 syntax. It
 would suck if build scripts start failing just because you 
 updated the
 symlink to a different compiler.

DMD and GDC are not drop in replacements for each other due to the differences, so a common symlink is IMO a bad idea right now. Even if your build scripts were able to deal with a compiler switch from DMD to/from CDC, the linking part will fail unless everything being linked was rebuilt using the now current compiler. --rt
Oct 03 2012