Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] PERFORCE change 71103 by Andrew Stitt for review

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Arwed von Merkatz <v.merkatz AT gmx.net>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] PERFORCE change 71103 by Andrew Stitt for review
  • Date: Thu, 8 Dec 2005 11:03:43 +0100

On Tue, Dec 06, 2005 at 10:24:02AM -0800, Seth Alan Woolley wrote:
> On Tue, Dec 06, 2005 at 06:30:06PM +0100, Arwed von Merkatz wrote:
> > On Tue, Dec 06, 2005 at 09:01:10AM -0800, Seth Alan Woolley wrote:
> > > All,
> > >
> > > Perhaps we should use this to do the gcc splitting. I think it would
> > > make more sense than what we have now that doesn't actually work all
> > > that well in corner cases.
> >
> > What doesn't work? The advantage with the current setup is that you
> > don't have to build five compilers just because you want to add fortran
> > to your existing 4 gcc compilers.
>
> Here's an example other than compiler option changing requiring a
> rebuild:
>
> When a spell needs g++ but only works on gcc34, even though gcc 3.4.x is
> what's in stable, it will install the null gcc34 spell, assume g++ 3.4.x
> is installed, and succinctly fail.
>
> So really there's one case where split spells work for c++ programs:
>
> You never change your archspecs or gcc version between compiling gcc and
> g++ and the spell works on gcc4 even if gcc 3.4 is installed. I can
> work on an up_trigger to fix the first one if we want to keep them
> split. The latter requires separate g++34 spells.
>
> Is CCACHE not good enough to avoid recompiling all of gcc?
>
> I'm just saying either the split spells need extra work or I'm delaying
> releasing stable until it's fixed. I'm running into tons of problems
> testing spells because I run into these issues whenever I go through a
> chroot testing cycle. It's easily repeatable.
>
> If we don't want to fix this issue but want stable released anyways, I'm
> putting in a big release note about how you probably want to do: cast -c
> g++ first thing after any update of gcc and for people to not expect g++
> being split to actually use dependency resolving correctly.

Imho this is the way to go, whatever we do with the gcc spells.
Sub-dependency support just made it to devel sorcery, so if we use that
stable grimoire release would be delayed quiet a while too until that
feature made it beyond our testing and into stable sorcery.
It's not a regression from the current stable grimoire, the issue
already exists, so imho it's not a good reason to delay releasing the
next one. Release it with that big warning and then make this issue a
blocker for the next stable release.

As to how to solve the issue, I'm tending towards sub_depends now, as
the split spells require quite a bit of (currently manual) work updating
the spec files for new releases. Adding an option to not use
profiled-bootstrap for those of us on slower systems should make the
compile time bearable. (profiled-bootstrap adds another pass for each
compiler)

> All I'm saying is that it needs some more work that doesn't seem to be a
> high priority for developers now. It's still causing problems for
> people. And as has been pointed out, I probably shouldn't be putting in
> fixes to bugs I find because I'll be the one responsible for testing
> them anyways.
>
> We either need them fixed or we need to revert to simpler behavior.
>
> Seth

--
Arwed v. Merkatz Source Mage GNU/Linux developer
http://www.sourcemage.org




Archive powered by MHonArc 2.6.24.

Top of Page