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!
:-)
