Public SourceMage Discussion List

[Arwed von Merkatz <v.merkatz AT gmx.net>]

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