Official compiler

[Radu via Digitalmars-d]

On Friday, 26 February 2016 at 13:11:11 UTC, Steven Schveighoffer 
wrote:
> On 2/26/16 7:02 AM, Radu wrote:
>> On Friday, 26 February 2016 at 11:01:46 UTC, Walter Bright 
>> wrote:
>>> I don't see anything unfair. gdc, ldc, and dmd are each as 
>>> good as
>>> their respective teams make them.
>>>
>>
>> The lack of fairness comes from the way the ecosystem is 
>> setup, you have
>> the reference compiler released, then everybody needs to catch 
>> up with
>> it. Why not have others be part of the official release? This 
>> will
>> undoubtedly increase the quality of the frontend and the glue 
>> layer, and
>> probably the runtime, just because they will be tested on more
>> architectures each release.
>>
>> No matter how you put it, both LDC and GDC are limited in 
>> manpower, and
>> also caught in the merge game with mainline. This is a bottle 
>> neck if
>> they need to attract more talent. Right of the bat you need to 
>> do a lot
>> of grunt work handling different repos, each at their own 
>> revision, plus
>> all the knowledge about build env and testing env.
>
> The issue here is the front-end not the back end. Daniel has 
> already stated this was a goal (to make the front end shared 
> code). So it will happen (I think Daniel has a pretty good 
> record of following through, we do have a D-based front end now 
> after all).
>
> Any effort to make both LDC and GDC part of the "official" 
> release would be artificial -- instead of LDC and GDC getting 
> released "faster", they would simply hold up dmd's release 
> until they caught up. And this is probably more pressure than 
> their developers need.
>
> When the front end is shared, then the releases will be 
> quicker, and you can be happier with it.
>
> -Steve

OK, a shared front end will be great!

My main concern is that if they are not integrated withing the 
daily pull-merge-auto-test loop they will always tend to drift 
and get out of sync while trying to fix stuff that breaks.

If the author of the pull request gets auto feedback from DMD and 
LDC on hes changes test results, than he will be aware of 
potential problems he might create.

The integration doesn't necessarily needs to be tightly coupled, 
i.e. LDC can keep its infrastructure and auto sync/run any merges 
from mainline. The issue is what to do with breaking changes.

Ideally, no breaking should be allowed for when fixing 
regressions or bugs, and any breaking on front-end or glue layers 
should at least be talked with the LDC/GDC guys.

All of the above needs steering from the leadership to follow 
trough.

And BTW, I'm happy with what D has become :), always room for 
improvements, thank you!