Am 11.05.2013 23:43, schrieb John Colvin:
On Saturday, 11 May 2013 at 21:09:57 UTC, Jonathan M Davis wrote:
On Saturday, May 11, 2013 20:40:46 deadalnix wrote:
Except that now, it is a pain to migrate old haskell stuff to
newer haskelle stuff if you missed several compile release.
You ends up building recursively from the native version to the
version you want.
Yeah. And I'm stuck with the opposite problem at the moment. I have to
be able
to build old haskell code without updating it, but I don't have an older
version of ghc built currently, and getting a version old enough to
compile my
code has turned out to be a royal pain, because the old compiler won't
compile
with the new compiler. I don't even know if I'm going to be able to do
it.
If you're always moving forward, you're okay, but if you have to deal
with
older code, then you quickly run into trouble if the compiler is
written in an
up-to-date version of the language that it's compiling. At least at this
point, if you needed something like 2.059 for some reason, you can
just grab
2.059, compile it, and use it with your code. But if the compiler were
written
in D, and the version of D with 2.059 was not fully compatible with the
current version, then compiling 2.059 would become a nightmare.
The situation between a normal program and the compiler is quite
different.
With a normal program, if your code isn't going to work with the current
compiler due to language or library changes, then you just grab an older
version of the compiler and use that (possibly upgrading your code
later if
you intend to maintain it long term). But if it's the compiler that
you're
trying to compile, then you're screwed by any language or library
changes that
affect the compiler, because it could very well become impossible to
compile
older versions of the compiler.
Yes, keeping language and library changes to a minimum reduces the
problem,
but unless they're absolutely frozen, you risk problems. Even changes
with
high ROI (like making implicit fall-through on switch statements illegal)
could make building older compilers impossible.
So, whatever we do with porting dmd to D, we need to be very careful.
We don't
want to lock ourselves in so that we can't make changes to the
language or
libraries even when we really need to, but we don't want to make it too
difficult to build older versions of the compiler for people who have
to either.
At the extreme, we could end up in a situation where you have to grab the
oldest version of the compiler which was written in C++, and then
build each
newer version of the compiler in turn until you get to the one that
you want.
- Jonathan M Davis
Can't this be eased with readily available binaries and cross compilation?
E.g. We drop the C++ version in 2.7. You want DMD version 2.8.2. The
minimum needed to compile 2.8.2 is 2.7.5:
You can download a binary of 2.7.5 for any common system, cross compile
2.8.2 for your development system, viola! If there are binaries
available for your development system, then it becomes almost trivial.
Even if this wasn't possible for some reason, recursively building
successive versions of the compiler is a completely automatable process.
dmd+druntime+phobos compiles quickly enough that it's not a big problem.
I also don't understand the problem. This is how compilers get
botstraped all the time.
You just use toolchain X to build toolchain X+1.
--
Paulo
