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