D compiler as part of GCC

[Jerry Quinn]

Brad Roberts Wrote:

> On 1/23/2010 4:15 PM, Walter Bright wrote:
> > Leandro Lucarella wrote:
> >> Walter Bright, el 23 de enero a las 12:54 me escribiste:
> >>> Jerry Quinn wrote:
> >>>> Walter Bright Wrote:
> >>>>> Will they take a fork of the dmd source, such that they own the
> >>>>> copyright to the fork and Digital Mars still has copyright to
> >>>>> the original?
> >>>> Hi, Walter,
> >>>>
> >>>> The answer appears to be yes:
> >>>>
> >>>> http://gcc.gnu.org/ml/gcc/2010-01/msg00430.html
> >>>>
> >>>> Jerry
> >>>>
> >>> That's great news. I suppose I should look over the forms they talk
> >>> about!
> >>
> >> Great news indeed! Since DMD FE is GPL I think it won't be any trouble to
> >> fold in the new changes back to GDC as they did (and LDC too), so it
> >> won't
> >> be really a *fork*, right?
> > 
> > Well, still I won't be supporting gdc directly. It would mean a team
> > that would be willing to take new DMD FE updates and fold them into GDC,
> > and then follow whatever gcc's build and release conventions are.
> 
> I don't think you got the answer you were looking for.  You got an answer to a
> different question.  If you assign the copyright over to the FSF, they then own
> the code.  You'd have a license to use it as you like in return, but you would
> no longer be the owner.

> Additionally, as pointed out in the gcc@ thread, contributions coming into the
> gcc tree wouldn't have anything other than the gpl license attached to them and
> that would likely make them problematic to re-distribute from your tree with the
> dual gpl/artistic license.
> 
> In simpler words, this is still far from straightforward.

I think you're slightly incorrect, Brad.  DigitalMars still owns the copyright to the original source (call it copy A).  A fork (called copy B) is donated to the FSF.   DigitalMars still gets to make changes to copy A and license them as it sees fit.  Copy B is part of the GCC codebase and would evolve separately.

Moving changes between them would require the same kind of donation process as the original transfer.  Folks making changes to the DMD FE would have to contribute those changes to FSF as well to get them into copy B and vice versa.

My apologies if that's the same as what you said.  I read your comment a couple of times and was a bit confused.
 
> I'd still love for there to be fewer split efforts on the compiler front, so I
> do encourage trying to find a workable solution.. but tread carefully.

The GCC java front end currently uses the Eclipse compiler to produce bytecode and then compiles the bytecode to native. But that's the only front end I'm aware of that isn't fully integrated into the GCC tree.

The D front end doesn't produce a portable intermediate representation like that so I think it would be harder to always use the latest DMD front end.

I see this possibility as Walter giving GCC a running start so that the D ecosystem has another viable compiler option available with relatively low effort.  

In the end, the language spec should be the thing that unifies the D community rather than the adhoc definition provided by a particular front end implementation.  It's just a matter of how to get there.

Later,
Jerry