This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Target-specific Front-Ends? (Was: front end changes for altivec)


Ziemowit Laski wrote:
> 
> Well, we do have a local tree, and it is a royal pain to maintain in sync
> with the FSF, as Stan can attest. :)

Unless Red Hat has significantly reduced their divergence recently,
Apple's local changes are probably still smaller than Red Hat's.
Our FSF import typically takes half a day, most of it spent waiting
for builds or cvs ops.

> In making my proposal, I assumed
> (perhaps wrongly) that a lot of other organizations are in the same
> boat --
> i.e., they have local modifications that they wouldn't mind putting into
> the FSF, but can't because GCC is not sufficiently modular (at least not
> for the front-end things) and the local things can't be kept sufficiently
> target-specific (hence interfering with the mainline).

The truth is that there aren't very many organizations who use
GCC on the same scale that Apple does.  None of the other big
computer vendors (Sun, HP, Compaq, etc) have adopted GCC as their
main or only compiler, and embedded system companies (with the
notable exception of Wind River) tend to use either an FSF or
Red Hat release as-is.

However, your proposal is still worth thought, because I believe
that the adoption of GCC by other system vendors is just a matter
of time, and they are going to face the same questions, whether
to adapt GCC to the environment or to adapt the environment to GCC.
The easy way out will always be to turn inwards and avoid working
with the community of GCC developers, but that's a sterile outcome
that we should all try to prevent.

Stan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]