Turn on failures when building DDMD with gdc-4.9.3

[ibuclaw]

Sets gdc compiler version to 4.9.3 and makes it a failure if builds fail.

[ibuclaw]

@MartinNowak - This is for you! GDC is the only one that passes TravisCI if I am to believe the build is correct. :-)

[jpf91]

ping @MartinNowak: Please update http://ftp.digitalmars.com/LATEST_GDC (or alternatively merge this pull request?).

[ibuclaw]

More importantly, will the Travis-CI testing be done for druntime and phobos PRs too. :-)

[ibuclaw]

Even more importantly. What is to stop @braddr 's auto-tester from automatically merging PR's if there's a failure in the Travis checks? Or does it consider all before merging?

[MartinNowak]

Great, it works.

ping @MartinNowak: Please update http://ftp.digitalmars.com/LATEST_GDC (or alternatively merge this pull request?).

Is this officially released yet? Otherwise we'd better only update dmd's config and rename it to something like gdc-4.9.3-dmd-preview instead (here is the regex).
Also I'd be in favor of hosting LATEST_GDC on gdcproject.org, only reason it's on ftp digitalmars is b/c I got no timely response from you guys.

[ibuclaw]

Which reminds me, that regex want work with gdc-5.x or later.

I don't recall such a request, but then again if it was around the beginning of this year, I wouldn't have picked it up.

I have no problem with hosting the file on my server.

[ibuclaw]

s/want/won't/

[MartinNowak]

Which reminds me, that regex want work with gdc-5.x or later.

I have no problem with hosting the file on my server.

So then let's just fix both things in a travis PR.

[MartinNowak]

Can you please put a LATEST file with 4.9.2 under gdcproject.org/downloads/LATEST @ibuclaw?

[MartinNowak]

Can you please put a LATEST file with 4.9.2 under gdcproject.org/downloads/LATEST @ibuclaw?

Ready when you are travis-ci/travis-build@master...MartinNowak:update_gdc.

[ibuclaw]

Ready when you are travis-ci/travis-build@master...MartinNowak:update_gdc.

Updated gdmd to work with gdc-5, didn't test any switch combinations other than straight compilation: https://github.com/D-Programming-GDC/GDMD/commits/master

Created file on the server (I've gone with 4.9.3) http://gdcproject.org/downloads/LATEST (alternate location ftp://ftp.gdcproject.org/LATEST)

I think that is all, no?

[MartinNowak]

I think that is all, no?

Yes, that's all travis-ci/travis-build#507.
I'd still say you're latest version should be 4.9.2 until 4.9.3 is officially released (or at least appears on the download site). We can manually select a gdc version for ddmd testing for the time being.

[ibuclaw]

I'd still say you're latest version should be 4.9.2 until 4.9.3 is officially released

In this case, the difference between the two is just maintenance fixes, both in the frontend and backend (frontend referring to just gdc). Which is how a point release should be.

I'm aware of user expectancy to have $latest_dmd and $previous_gcc working together, but it should be noted that the hard work done doubling/tripling our workload for backporting new dmd releases to gdc release branches will only last as long as we're a separate entity to gcc though. ;-)

[ibuclaw]

Updated commit message and PR title from test to live.

Pinging people who I think should be aware: @MartinNowak @yebblies @WalterBright @jpf91

[MartinNowak]

I'm aware of user expectancy to have $latest_dmd and $previous_gcc working together, but it should be noted that the hard work done doubling/tripling our workload for backporting new dmd releases to gdc release branches will only last as long as we're a separate entity to gcc though. ;-)

What's the release cycle for GCC?
I think it would still be helpful to continuously integrate frontend updates, so we get feedback for problematic features much earlier. I'd guess that would also spread the workload more evenly when you don't try to merge a single release.
Also we're very open to gdc/ldc specific changes to dmd/druntime, which should reduce your work as compared to keeping those changes in your forks.

[ibuclaw]

What's the release cycle for GCC?

Roughly speaking: Once every 12 months for a major, and 3 every months for a maintenance (but this typically drags out as time goes on).

The number of maintenance releases varies so far between 4 and 8 for a particular major version, but I'd imagine that OS vendors with LTS releases have some leverage over of what is and is not given a longer maintenance cycle.

Translating this into GDC's relationship with DMD. It means that jumps to the next supported version of D2 will happen once a year, and will only receive backported bug fixes thereafter for the next year or so. If there are maintenance releases for the upstream DMD version, then these will be allowed in too.

I think it would still be helpful to continuously integrate frontend updates, so we get feedback for problematic features much earlier. I'd guess that would also spread the workload more evenly when you don't try to merge a single release.

Yes, it helps if GDC master is only 1 week behind DMD master. Then, in preparation for when the GCC development (aka stage1) window closes, one of the following will be done:

• If there's a new release branch for DMD (eg: alpha, beta, rc), or one is expected to open within weeks, switch to it.
• If a new release has already gone out, use that release branch (because, the next upstream release will not align with the closing of stage3 - the freeze in GCC before official release).

Branching will not affect master keeping up with it's weekly sync with DMD master, only that a call for rigorous testing to be done prior the next GDC release - and possibly benefits the next DMD release too. :-)

Also we're very open to gdc/ldc specific changes to dmd/druntime, which should reduce your work as compared to keeping those changes in your forks.

I'm more open to suggesting common APIs for each compiler to interface to. So long as they are within reason (eg: the setting up _argptr in the front-end should be moved to such a common interface such as Target).