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.

Valid point, never thought about that problem before.

> Is CCACHE not good enough to avoid recompiling all of gcc?

Does ccache work for gcc? I very much doubt it as ccache is a wrapper
around gcc, which doesn't get used by the gcc cast except for
bootstrapping, which is the smallest part of the cast.
The point of the split spells is that they make it actualle feasible to
e.g. 'cast fortran' to test some fortran spell. If I had to recompile
all of gcc, g++, ada, objc and gcj just to add fortran support, I'd
never do it as that takes 8+ hours.
The spells were originally split to make dependency handling easier, so
re-joining them now that we have sub-depends would be the obvious path,
but I think the split spells have the above advantage, so it might be
worth fixing the issue in other ways.
I'm really not sure which way I'd prefer right now, just thought I'd
point out the advantages of the split.

> 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.
> 
> 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