On Monday, 24 July 2017 at 23:25:50 UTC, Martin Nowak wrote:
On Monday, 24 July 2017 at 22:15:16 UTC, Moritz Maxeiner wrote:
One thing to watch out for, though, is that if the D frontend starts using features introduced after its conversion to D, we are going to need to explicitly document the bootstrapping path (right now it's still simple enough with `C++ compiler -> D compiler with 2.068.2 frontend (e.g. ldc 0.17.x) -> Latest D compiler`).

We're using the latest previous major release line to build releases, so 2.068.x build 2.069.x, builds 2.070.x, ..., builds 2.075.0.

That's a sensible choice for the official binary distribution.

You might get away with skipping versions, but that's not how the releases were built.

When you bootstrap (e.g. on any source based Linux distribution such as Gentoo, Funtoo, ...) you want the path to be as short as feasible (even with dmd's fairly short compile times) and how the official binary releases are/were build isn't part of the consideration, because - unlike them - you don't happen to have a D compiler with D frontend version - 1 ready for use. In any case, all that would be required - if the path ever becomes longer - would be an automatically updated file like this:


An autotester can then check before each release if dmd master can still be build by dmd with the version of the last line in that file, and if not, append the last dmd release to it.

Reply via email to