[SM-Discuss] RFC: combining all gcc frontends into a single spell

Arwed von Merkatz v.merkatz at gmx.net
Mon Jul 20 14:06:01 EDT 2009


On Sun, Jul 19, 2009 at 03:28:25PM +0800, Peng Chang (Charles) wrote:
> Dear all,
> 
> After compiling Source Mage for several times. I noticed that compiling
> the compilers consumes much more time than necessary, for all gcc
> frontends bootstrap gcc the C compiler first, whichk takes over 30
> minutes on a Core2 Duo 2.0GHz machine with make -j5, and then compiles
> the compiler requested.
> 
> There are other flaws with this approach as well:
> 1. The gcc bootstrapped each time cannot be guaranteed to be the same.
>    This may matter if you are highly concerned about the consistency and
>    interoperability between compilers.
> 2. Re have to maintain the spec files manually, which can be generated
>    automatically.
> 3. To be discussed...
> 
> As I discussed with ruskie ealier today, we may combine the frontends
> into a single spell, with the frontends as sub_depends of the spell.
> 
> Advantages:
> 1. This saves time because gcc gets compiled once.
> 2. The compilers interact perfectly.
> 3. The structure of the spell is clear and easy.
> 4. To be discussed...
> 
> Disadvantages:
> 1. This saves time only when someone decides what compilers to have
>    early.
> 2. If someone wants to dispel/modify a single compiler, it consumes more
>    time. (Who wants to do this?)
> 3. To be discussed...
> 
> We also need to think about how to support non-official frontends in
> this approach.

I agree that combining the spells again is probably a good idea. The
original separation happened mostly because we didn't have SUB_DEPENDS
at the time, so this was the only way to make sure spells could depend
on the compiler for the language they needed.
If this makes it possible to make gmp and mpfr internal to gcc, that
would be a welcome advantage, circular depends are nasty when you run
into problems.
-- 
Arwed v. Merkatz                              Source Mage GNU/Linux developer
                                                    http://www.sourcemage.org


More information about the SM-Discuss mailing list