On Tue, 2016-04-12 at 01:58 +0000, Matthias Klumpp via Digitalmars-d- announce wrote:
> On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton Wakeling wrote:
> > 
> > On Monday, 11 April 2016 at 14:21:46 UTC, Matthias Klumpp wrote:
> > > 
[…]

> > Curious question: what's the Debian policy these days on what D compiler should be used to build D packages?
> There is no real policy, at least I have found none. But from my tests, ldc simply crashed right away when trying to compile, later it wasn't able to process some code gdc had no problems with (I haven't tried the upcoming release). Since the GNU Compiler Collection is Debian's default compiler, I have set the compiler dependency of dub to gdc | ldc | d-compiler, so gdc is preferred, but replacing it with any other compiler will work too.

If the Debian ldc2 compiler is crashing on the same source that gdc compiles that sounds like a packaging problem. Or use of outdated D? ldc is generally much more up to date that gdc so shouldn't the order be ldc | gdc | d-compiler?

On Debian Sid ldc2 is 2.068.2 and gdc doesn't advertise which version of D it is.

I assume that the DMD package from dlang, or better d-apt, sets the d- compiler property. Should dmd be prefered if it is present?

> > 
> > And has dub's config been tweaked accordingly in terms of which compiler it prefers to use ... ?
> I didn't touch that, since dub seems to automatically find the right compiler. The preference seems to be dmd >> gdc >> ldc2, which looks sane to me.

Sane, yes, but dmd → ldc2 → gdc is probably a better choice simply because ldc tends to be more up to date than gdc – this is not a maintainer problem just a release flow problem.

> It's really bad that GDC isn't part of the official GCC yet, and the standard libraries differ so much between the compilers (mainly due to phobos progressing very quickly).

GDC is definitely ipart of the GCC thanks to Iain's ongoing efforts, with support from others. GDC would not be in the Debian repository if it wasn't part of GCC.

The problem here is that the Fedora GCC packagers package GCC-Go but do not package GDC. This means GDC is not present in any of Fedora, CentOS, RHEL, Scientific Linux.

The last on this list is more important than you might think.

Also the ldc package in Rawhide is only 0.16.1 which is really rather ancient.

> For Debian Stretch I assume the situation will be much better
> though :-) (given the state of the LDC and GDC Git repos).

I think the policy simply has to be to make sure that LDC and GDC are as up to date as possible in Sid ­– which already happens – and in Fedora Rawhide – which no-one but me seems to think is important.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 12 April 2016 at 02:42:09 UTC, jmh530 wrote:
> On Monday, 11 April 2016 at 14:21:46 UTC, Matthias Klumpp wrote:
>>
>> On the roadmap are adding debhelper sequences to simplify packaging dub-based D code in Debian based distros, auto-test support in Debian's CI, and of course the usual bugfixing.
>>
>
> Is adding to Linux Mint something you would consider as well?

That's up to the Mint people, I only can speak for Debian and to a limited degree for Ubuntu.
Since Mint bases on Ubuntu LTS releases, it is pretty certain though that this will be available via the Ubuntu Xenial sources.

On Tuesday, 12 April 2016 at 07:03:44 UTC, Russel Winder wrote:
> [...]
>
> If the Debian ldc2 compiler is crashing on the same source that gdc compiles that sounds like a packaging problem. Or use of outdated D? ldc is generally much more up to date that gdc so shouldn't the order be ldc | gdc | d-compiler?

I didn't get it to compile properly with LDC, which might of course have been due to the outdated LDC version in Debian and Ubuntu at that time.
Also, GDC is available for more architectures and wasn't stuck in unstable at the time dub was packaged.

> On Debian Sid ldc2 is 2.068.2 and gdc doesn't advertise which version of D it is.

Should be D2, there doesn't seem to be much D1 code around anymore...

> I assume that the DMD package from dlang, or better d-apt, sets the d- compiler property. Should dmd be prefered if it is present?

I think so, since when installing it from non-free 3rd-party sources, the user made an explicit choice for DMD.
In terms of packaging, the packaging doesn't really care, any D compiler will satisfy the requirements of the dub package.

>> > And has dub's config been tweaked accordingly in terms of which compiler it prefers to use ... ?
>> I didn't touch that, since dub seems to automatically find the right compiler. The preference seems to be dmd >> gdc >> ldc2, which looks sane to me.
>
> Sane, yes, but dmd → ldc2 → gdc is probably a better choice simply because ldc tends to be more up to date than gdc – this is not a maintainer problem just a release flow problem.

I can't comment on that... In any case, users and packagers can choose whatever D compiler they prefer, there is no "enforcement" of any kind happening (just default choices).

>> It's really bad that GDC isn't part of the official GCC yet, and the standard libraries differ so much between the compilers (mainly due to phobos progressing very quickly).
>
> GDC is definitely ipart of the GCC thanks to Iain's ongoing efforts, with support from others. GDC would not be in the Debian repository if it wasn't part of GCC.

That's unfortunately not the case. If you download gcc-5_5.3.1.orig.tar.gz from https://packages.debian.org/source/sid/gcc-5 , you can see that GDC was manually inserted. I think the problem might lie in the GDC frontend code not being subjected to the FSF CLA, but that's just a guess - Iain likely knows more :)

> The problem here is that the Fedora GCC packagers package GCC-Go but do not package GDC. This means GDC is not present in any of Fedora, CentOS, RHEL, Scientific Linux.
>
> The last on this list is more important than you might think.

Coming from a scientific background, I am with you on this... Problem again is that gccgo is part of GCC, so you just need to enable it, while gdc is out-of-tree.

> Also the ldc package in Rawhide is only 0.16.1 which is really rather ancient.

Jup - to be honest, I think the state of the free compilers in Linux distributions is really something which is limiting D the most at time.
New programming languages like Rust have it much easier in that regard.

>> For Debian Stretch I assume the situation will be much better
>> though :-) (given the state of the LDC and GDC Git repos).
>
> I think the policy simply has to be to make sure that LDC and GDC are as up to date as possible in Sid ­– which already happens

Jup - ideally, the Debian D team would give some advice on default compilers and versions. But that team seems to be dead.

> – and in Fedora Rawhide – which no-one but me seems to think is important.

Ideally find a Fedora developer (who ideally also works on RHEL) and convince him. The easiest way to get the compiler in would be a killer application written in D which requires an up-to-date toolchain. E.g. Docker is written in Go, many people want Docker, so Go is up-to-date (that's over-simplified, but it generally works that way...).

Cheers,
    Matthias

El 12/04/16 a les 14:26, Matthias Klumpp via Digitalmars-d-announce ha escrit:
>> I assume that the DMD package from dlang, or better d-apt, sets the d- compiler property. Should dmd be prefered if it is present?
> 
> I think so, since when installing it from non-free 3rd-party sources, the user made an explicit choice for DMD.
> In terms of packaging, the packaging doesn't really care, any D compiler will satisfy the requirements of the dub package.


No, dmd deb packages from dlang and d-apt do not set any d-compiler property. Where should it be set?

On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp wrote:
> On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton Wakeling wrote:
>> Related note: I see the lcd version in xenial is 0.17.0~beta2 -- I don't suppose there's any chance of upgrading that to the stable 0.17.1 release ... ?  (Not asking you to do it personally, just wondering if that's something that could be achieved.)
>
> I can ask, but given that the Xenial final freeze is on 24. April (release on 26.) and changing compiler versions that late in the cycle is potentially dangerous, I guess there is only a slim chance of success... On the pro-side is that having a beta compiler in the LTS release is undesirable, but even then I need to find an Ubuntu developer who does have time to do the sync and get the feature-freeze-exception. LDC FTBFSing on armel in Debian (and not entering testing due to that at time) is also an issue :-/

Ouch :-(  Well, if you are happy to look into it, that would be great -- no pressure, though. :-)

I get the point about not updating compilers late in the development cycle, but this update is likely to produce a better package and I can't see it triggering any other package rebuilds beyond the LDC phobos/druntime packages.

BTW, the package description for ldc, in both Debian and Ubuntu, is insanely out of date: it reads,

   LDC already compiles a lot of D code, but should still be
   considered beta quality. Take a look at the tickets to get
   a better impression on what still needs to be implemented.

... which AFAICT is unchanged from something like 5+ years ago, when the ldc packaged in Debian/Ubuntu was a D1-only compiler still in heavy development.

> There is no real policy, at least I have found none. But from my tests, ldc simply crashed right away when trying to compile, later it wasn't able to process some code gdc had no problems with (I haven't tried the upcoming release). Since the GNU Compiler Collection is Debian's default compiler, I have set the compiler dependency of dub to gdc | ldc | d-compiler, so gdc is preferred, but replacing it with any other compiler will work too.

That's very odd.  What were you trying to build ... ?

> I didn't touch that, since dub seems to automatically find the right compiler. The preference seems to be dmd >> gdc >> ldc2, which looks sane to me.

Yea, sounds good.

Related note: would it be viable in principle to get dmd itself into Debian and Ubuntu repositories via (respectively) non-free and multiverse ... ?  Again, not asking you to do the work, but just curious based on your experience of being a Debian packager.

> For Debian Stretch I assume the situation will be much better though :-) (given the state of the LDC and GDC Git repos).

Looking forward to it :-)  And, thank you again!

On Tuesday, 12 April 2016 at 13:28:29 UTC, Jordi Sayol wrote:
> El 12/04/16 a les 14:26, Matthias Klumpp via Digitalmars-d-announce ha escrit:
>>> I assume that the DMD package from dlang, or better d-apt, sets the d- compiler property. Should dmd be prefered if it is present?
>> 
>> I think so, since when installing it from non-free 3rd-party sources, the user made an explicit choice for DMD.
>> In terms of packaging, the packaging doesn't really care, any D compiler will satisfy the requirements of the dub package.
>
>
> No, dmd deb packages from dlang and d-apt do not set any d-compiler property. Where should it be set?

I think with "property" you mean "virtual package". See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
Basically, the dmd package needs a "Provides: d-compiler" line, then it should be able to satisfy the dependencies of the dub package.

On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton Wakeling wrote:
> On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp wrote:
>> On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton Wakeling wrote:
>>> Related note: I see the lcd version in xenial is 0.17.0~beta2 -- I don't suppose there's any chance of upgrading that to the stable 0.17.1 release ... ?  (Not asking you to do it personally, just wondering if that's something that could be achieved.)
>>
>> I can ask, but given that the Xenial final freeze is on 24. April (release on 26.) and changing compiler versions that late in the cycle is potentially dangerous, I guess there is only a slim chance of success... On the pro-side is that having a beta compiler in the LTS release is undesirable, but even then I need to find an Ubuntu developer who does have time to do the sync and get the feature-freeze-exception. LDC FTBFSing on armel in Debian (and not entering testing due to that at time) is also an issue :-/
>
> Ouch :-(  Well, if you are happy to look into it, that would be great -- no pressure, though. :-)
>
> I get the point about not updating compilers late in the development cycle, but this update is likely to produce a better package and I can't see it triggering any other package rebuilds beyond the LDC phobos/druntime packages.
>
> BTW, the package description for ldc, in both Debian and Ubuntu, is insanely out of date: it reads,
>
>    LDC already compiles a lot of D code, but should still be
>    considered beta quality. Take a look at the tickets to get
>    a better impression on what still needs to be implemented.
>
> ... which AFAICT is unchanged from something like 5+ years ago, when the ldc packaged in Debian/Ubuntu was a D1-only compiler still in heavy development.
>
>> There is no real policy, at least I have found none. But from my tests, ldc simply crashed right away when trying to compile, later it wasn't able to process some code gdc had no problems with (I haven't tried the upcoming release). Since the GNU Compiler Collection is Debian's default compiler, I have set the compiler dependency of dub to gdc | ldc | d-compiler, so gdc is preferred, but replacing it with any other compiler will work too.
>
> That's very odd.  What were you trying to build ... ?

This is likely a packaging issue - I tried this again on Xenial, and got
```
Warning: failed to locate the configuration file ldc2.conf
Error: cannot find source code for runtime library file 'object.d'
       ldc2 might not be correctly installed.
```
So yeah, this doesn't look like an upstream issue. I'll play around with LDC a bit more (and update it to a non-beta version, and maybe to Git master), maybe this evening - I really want std.concurrency.Generator, which GDC doesn't provide and which I currently embed in my code. The better std.getopt in newer standard library versions would also be nice (not sure how recent that is in LDC).

>> I didn't touch that, since dub seems to automatically find the right compiler. The preference seems to be dmd >> gdc >> ldc2, which looks sane to me.
>
> Yea, sounds good.
>
> Related note: would it be viable in principle to get dmd itself into Debian and Ubuntu repositories via (respectively) non-free and multiverse ... ?  Again, not asking you to do the work, but just curious based on your experience of being a Debian packager.

For non-free/multiverse: Maybe. Proprietary compilers are generally something not liked very much in the Debian community, and pushing the free compilers would be seen as the much better approach.
That being said, if someone wants to do the work and do proper packaging of dmd, nobody would stop that work being done either.

>> For Debian Stretch I assume the situation will be much better though :-) (given the state of the LDC and GDC Git repos).
>
> Looking forward to it :-)  And, thank you again!

:-)

On Thursday, 14 April 2016 at 16:05:04 UTC, Matthias Klumpp wrote:
> On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton Wakeling wrote:
>> On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp wrote:
>>> On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton [...]
>>> I can ask, but given that the Xenial final freeze is on 24. April (release on 26.) and changing compiler versions that late in the cycle is potentially dangerous, I guess there is only a slim chance of success... On the pro-side is that having a beta compiler in the LTS release is undesirable, but even then I need to find an Ubuntu developer who does have time to do the sync and get the feature-freeze-exception. LDC FTBFSing on armel in Debian (and not entering testing due to that at time) is also an issue :-/
>>
>> Ouch :-(  Well, if you are happy to look into it, that would be great -- no pressure, though. :-)

FTR, I filed https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1570006 - if we are lucky, this still has a chance to go in.

As for further dub stuff, it is important that https://github.com/D-Programming-Language/dub/issues/811 is addressed, so we can build software using dub without downloading stuff from the internet.
Btw, since D doesn't know traditional headers like C/C++, how would I link against a library without having the full sourcecode present somewhere?

Ideally, we would compile something like mustache-d[1] when building a .deb package for it, then have a dependency on that library pick up the prebuilt static library (or dynamic library, ideally, if there is one) and link against it (so we don't rebuild the code over and over again).
There doesn't seem to be a way though to export the interfaces a D library provides to link against a D library at time, so we likely would need to ship the full source additionally to the D library in the -dev package, and have dub figure out the details (make it pick up the existing binary instead of recompiling the module)...
These issues need to be solved for any distro, not only Debian, before packaging D code that is using dub becomes easily possible (ideally, a solution exists already, that I just don't know about yet ^^).

[1]: https://github.com/repeatedly/mustache-d

Am Thu, 14 Apr 2016 16:29:31 +0000
schrieb Matthias Klumpp <matthias@tenstral.net>:

> On Thursday, 14 April 2016 at 16:05:04 UTC, Matthias Klumpp wrote:
> > On Tuesday, 12 April 2016 at 16:57:41 UTC, Joseph Rushton Wakeling wrote:
> >> On Tuesday, 12 April 2016 at 01:58:13 UTC, Matthias Klumpp wrote:
> >>> On Monday, 11 April 2016 at 21:58:55 UTC, Joseph Rushton [...] I can ask, but given that the Xenial final freeze is on 24. April (release on 26.) and changing compiler versions that late in the cycle is potentially dangerous, I guess there is only a slim chance of success... On the pro-side is that having a beta compiler in the LTS release is undesirable, but even then I need to find an Ubuntu developer who does have time to do the sync and get the feature-freeze-exception. LDC FTBFSing on armel in Debian (and not entering testing due to that at time) is also an issue :-/
> >>
> >> Ouch :-(  Well, if you are happy to look into it, that would be great -- no pressure, though. :-)
> 
> FTR, I filed https://bugs.launchpad.net/ubuntu/+source/ldc/+bug/1570006 - if we are lucky, this still has a chance to go in.
> 
> As for further dub stuff, it is important that
> https://github.com/D-Programming-Language/dub/issues/811 is
> addressed, so we can build software using dub without downloading
> stuff from the internet.
> Btw, since D doesn't know traditional headers like C/C++, how
> would I link against a library without having the full sourcecode
> present somewhere?
> 

(1) Interface files

We have .di interface files as a replacement for C/C++ headers (although the .di extension is only a convention, you can also use the .d extension). These files do not contain function bodies, but they still need the complete source code for templates. The compilers can generate interface files from normal source code.

https://dlang.org/dmd-linux.html#interface-files

OSS projects do not use interface files though: It prevents inlining of functions and there's no real benefit for OSS projects. Interface files are (theoretically) useful for closed source libraries if you don't want to ship the source code.


(2) Linking against installed libraries

The compilers can of course link against pre-compiled D libraries. IIRC dub does not have integrated support for this. The real problem is the D compilers are not ABI compatible. If you built a library with GDC you can't use it with LDC or DMD. This is one reason why dub compiles everything from source. (Even different frontend versions can sometimes break ABI compatibility).

El 14/04/16 a les 17:54, Matthias Klumpp via Digitalmars-d-announce ha escrit:
> On Tuesday, 12 April 2016 at 13:28:29 UTC, Jordi Sayol wrote:
>> El 12/04/16 a les 14:26, Matthias Klumpp via Digitalmars-d-announce ha escrit:
>>>> I assume that the DMD package from dlang, or better d-apt, sets the d- compiler property. Should dmd be prefered if it is present?
>>>
>>> I think so, since when installing it from non-free 3rd-party sources, the user made an explicit choice for DMD.
>>> In terms of packaging, the packaging doesn't really care, any D compiler will satisfy the requirements of the dub package.
>>
>>
>> No, dmd deb packages from dlang and d-apt do not set any d-compiler property. Where should it be set?
> 
> I think with "property" you mean "virtual package". See https://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual
> Basically, the dmd package needs a "Provides: d-compiler" line, then it should be able to satisfy the dependencies of the dub package.

Thanks. What happen is multiple packages, all of them not installed, sets "Provides: d-compiler"? Which one is installed?