Re: Important: Development Plan for Future Releases

[Mark Mitchell <mark at codesourcery dot com>]

> Hmm... to a casual observer like myself it seems that adding a _new_
> microprocessor port is less risky than _modifying_ an existing port to
> add a new variant.  Why shouldn't this be allowed?

It should be.  In fact, there's talk of adding a new port to the GCC
3.0 branch, and I think that's fine, as long as the new code is
in decent shape, and there's little or no impact on existing code.

> "target" shows up more than "host" in this note.  What about regressions
> on different host platforms?

That matters too.  You can read "host" for "target" throughout, I
think.

> Ignoring test code, I believe that more than half of the source files in
> GCC are part of some target library and not the compiler.  Your note has
> very little to say about target libraries.  Am I right to assume that the
> library maintainers are to work within the spirit of this plan, but have
> more flexibility?

I'm not sure how much more flexibility makes sense.  If I can't build
the library, I can't really use the compiler, so it's just as broken,
in many ways.  So, I don't think reading anything specially for libraries 
was what was intended.  (It's a little confusing, because I know exactly 
what I intended, but I don't know exactly what the SC intended,
collectively so I'm hedging a little bit.)

Java has gotten special treatment up until now because it's been in
such a formative state.  I think it's reasonable to continue operating
in that mode a little while longer, but then now that the GCC 3.0 release
is out, with pretty good Java support, I think we need to start treating
it pretty much like the rest of the system.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com