[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