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!


Reply via email to