gdc in Linux distros recommended?

[Nick Sabalausky via Digitalmars-d]

On 10/19/2016 05:13 PM, Iain Buclaw via Digitalmars-d wrote:
> On 19 October 2016 at 18:01, Nick Sabalausky via Digitalmars-d
>>
>> The last GDC release is stuck all the way back at DMDFE v2.066, which is
>> over two years old. Very few libs/projects are going to still be supporting
>> that, there's just too much limitation going back that far. LDC had been
>> keeping up much better.
>
...
> And GDC is using the 2.068 feature set, plus a lot of bug fixes from
> later versions.  I guess you could call it 2.068.5.  :-)
>

Maybe there's a certain amount of truth to that, but not completely: In 
all my projects anyway, the latest available GDC on travis always broke 
at exactly the same time DMD 2.066 and below broke. I don't think I have 
any remaining projects that still work on GDC, but several still work on 
DMD 2.067.1 (not sure about 2.067.0, don't use that one in my 
.travis.yml files since 2.067.1 came out).

Maybe there's a newer GDC build that isn't on travis yet? Current 
lastest (using "gdc" in .travis.yml), checked as of 13 hours ago, is 
reporting this:

gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 
20150825-2.066.1-58ec4c13ec) 4.9.3

There's also a "gdc-5.2.0" that (checked as of this past April, anyway - 
not sure if there would be a newer "gdc-5.2.0" though), reports:

gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 
20150825-2.066.1-dadb5a3784) 5.2.0


>> If his lib isn't tested to support up-to-date D compilers (especially the
>> import changes in 2.070, but there's other stuff as well), that's going to
>> prevent a lot of people from being able to use his lib. So much for
>> availability to the masses.
>>
>
> The fixes to import behaviour only breaks forwards compatibility, not
> backwards compatibility.
>

Not sure what your point is here. If you're writing a library and want 
to avoid giving your users deprecation messages due to the import 
changes, then you need to test on 2.070 or newer. Clean compilation on 
pre-2.070 does not guarantee clean compilation on 2.070+.

> The problem with compatibility is a library problem, not a compiler IMO.
>

Since compiler versions and druntime/phobos versions are still pretty 
much a packaged deal, the distinction is irrelevent.