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

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

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

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

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

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