Migrating D front end to D - post Dconf

[Jesse Phillips]

On Saturday, 11 May 2013 at 15:09:24 UTC, Iain Buclaw wrote:
> Actually, the more I sit down and think about it, the more I 
> question
> whether or not it is a good idea for the D D front end to have 
> a dependency
> on phobos.   Maybe I should stop thinking in general.  :)
>
> Regards

Let me restate the issues to be clear on what I think is being 
said, and the my opinion.

== On GDC:

There is an flag to have the compiler built without dependencies 
of druntime/phobos. Someone interested in a Phobos free compiler 
would the be required to have Phobos to build their compiler.

- While this is the same person, I don't see that they will 
require the same restriction when building the compiler. My guess 
is the environment used to build the compiler has fewer 
restrictions, such as the having gcc/ubuntu available. Thus it is 
reasonable to expect them to have the needed libraries to build 
their compiler.

- Similarly, even if we restrict to just using druntime, the one 
interested in a druntime free compiler still runs into the issue.

== On Compiling older Compilers:

Checkout compiler source for an older compiler and gcc will build 
it. By switching to D, not only do we locate the source for the 
compiler we are building we must have the version of D used to 
build that compiler (or within the some window)

- I think it would be positive to say, each dmd version compiles 
with the previous release and itself (possibly with -d). This 
gives a feel for what changes are happening, and the more Phobos 
used the better.

- We can't eliminate the problem, if we only rely on druntime, 
everything still applies there. Instead we just need a consistent 
and/or well documented statement of which compiler versions 
compile which compiler versions.

In conclusion, it is a real problem. But it is nothing we can 
eliminate. We should look at reducing the impact not through 
reducing the dependency, but instead through improvement of our 
processes for introducing breaking changes. Such concentration 
will not be limited to benefiting DMD, but instead every project 
which must deal with older code in some fashion.