This is the mail archive of the
mailing list for the GCC project.
Re: Target-specific Front-Ends? (Was: front end changes for altivec)
- From: Stan Shebs <shebs at apple dot com>
- To: Ziemowit Laski <zlaski at apple dot com>
- Cc: Per Bothner <per at bothner dot com>, Ira Ruben <ira at apple dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 27 Nov 2001 18:34:52 -0800
- Subject: Re: Target-specific Front-Ends? (Was: front end changes for altivec)
- References: <755E7B73-E3A4-11D5-AE62-0030658361CA@apple.com>
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.