Skip to Content.
Sympa Menu

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

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Ethan Grammatikidis <eekee57 AT fastmail.fm>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] RFC: combining all gcc frontends into a single spell
  • Date: Sun, 19 Jul 2009 10:40:52 +0100

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.




Archive powered by MHonArc 2.6.24.

Top of Page