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:
As part of that work, the dub package an build management system is now available in Debian, and I will ensure it works well. Additionally, it was possible to make dub available late in the Ubuntu 16.04 (Xenial) development cycle, so dub will also be part of the upcoming LTS release of Ubuntu (kudos here go to Matthias Klose for pointing me at the "new" --push-state linker directive to work around dub not linking properly against libcurl when the latter is compiled with --as-needed).


That's great news.  Thank you very much!

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

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.

That sounds very cool. I'm very grateful that you are doing this work; it's going to save me my usual from-source install, and looks like it opens the gates for a bunch more D code getting into the Debian + Ubuntu universe.

Yes, that's the plan - for this to happen, we need some additions to dub though, to search in common global paths for packages. I opened bug https://github.com/D-Programming-Language/dub/issues/811 for that. Until that's fixed, I can't package more D code using dub (and adding debhelper bits also depends on this being resolved).

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.

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.

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

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

Reply via email to