Public SourceMage Discussion List

[Ethan Grammatikidis <eekee57 AT fastmail.fm>]

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.