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

Ethan Grammatikidis eekee57 at fastmail.fm
Sun Jul 19 05:40:52 EDT 2009


On Sun, 19 Jul 2009 15:28:25 +0800
"Peng Chang (Charles)" <chp516 at gmail.com> 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.

I imagine the majority of compiles in most SMGL systems are upgrades so this should save time overall.

> 2. If someone wants to dispel/modify a single compiler, it consumes more
>    time. (Who wants to do this?)

I sometimes dispel all sorts of things for the purpose of keeping my machine free from unnessecery junk. Whenever I "tidy up" like this there is always some large spells which need to be rebuilt. (It's always the large ones.)

> 3. To be discussed...
> 
> We also need to think about how to support non-official frontends in
> this approach.
> 
> Cheers,
> Charles
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss at lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss


-- 
Ethan Grammatikidis

Those who are slower at parsing information must
necessarily be faster at problem-solving.


More information about the SM-Discuss mailing list