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: flux <flux AT sourcemage.org>
  • 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 08:16:56 -0400

Peng Chang (Charles) (chp516 AT gmail.com) wrote [09.07.19 03:42]:
> 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 think if someone is building things with ccache enabled this won't
necessarily be true. If someone later decides that they want g++, then
later on they want gfortran, etc., then the gcc core will be
bootstrapped each time anyway, so the amount of extra time wouldn't be
huge I think. Also, if they happen to decide to add extra features
around the same time that a new gcc version is out, then they will need
to rebuild all of it anyway in order to upgrade, so it would actually
cost MORE time doing this at the same time as an upgrade than if the
spells were combined. If not during an upgrade but ccache is enabled,
the extra time might only be a few minutes, which is certainly bearable
for all the advantages we gain.

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

I think that we might be able to do some hackery (or at least the person
interested in dispelling a single compiler) where just those parts are
removed from their system. Even when g++ is built as part of the gcc
spell, the files are still separate, so in theory we could reap just the
g++ files off the system. I don't know if this should become an official
way of doing things, or just left as an option to those daring enough to
try, but it's possible and would not consume more time (except for the
little bit of manpower needed to do the hackery).

> 3. To be discussed...
>
> We also need to think about how to support non-official frontends in
> this approach.

This could still be done via separate spells the way the frontends are
now (just because we integrate all the others into a single spell
doesn't mean we have to continually ONLY have a single gcc spell) if
including them into the unified gcc spell wouldn't work for some reason.

> Cheers,
> Charles

DYEW IT!! (in a really bad Austrian accent)
:-D

I think Ada will give us problems no matter what. We already have
problems with it when doing the front-ends as separate spells and
bootstrapping gcc each time. The problem set may be different having it
all combined, but either way Ada is problematic. It should probably die
anyway. :-P

--
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpdYVsh3IFi_.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page