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
