Re: [RFC] Our release cycles are getting longer

[Marcin Dalecki <martin at dalecki dot de>]

Wiadomość napisana w dniu 2007-01-24, o godz04:32, przez Andrew Pinski:


> > It's "too good" to be usable. The time required for a full test suite
> > run can be measured by days not hours.
>
> Days, only for slow machines.  For our PS3 toolchain (which is really
> two sperate compilers), it takes 6 hours to run the testsuite, this
> is doing one target with -fPIC.  So I don't see how you can say it
> takes days.

Quantitatively:

gcc/testsuite dalecki$ find ./ -name "*.[ch]" | wc
    6644    6644  213514
ejh216:~/gcc-osx/gcc/testsuite dalecki$ find ./ -name "*.[ch]" -exec  
cat {} \; | wc
  254741 1072431 6891636

That's just about a quarter million lines of code to process and you
think the infrastructure around it isn't crap on the order of 100?  
Well... since
one "can drive a horse dead only once" the whole argument could  
actually stop here.

> No, not really, it took me a day max to get a spu-elf cross compile
> building and runing with newlib and all.

Building and running fine, but testing??? And I guess of course that  
it wasn't
a true cross, since the SPUs are actually integrated in to the same  
OS image as
the main CPU for that particular target.

> > > My favorite tactic to decrease the number of
> > > bugs is to set up a unit test framework for your code base (so  
> > > you can
> > > test changes to individual functions without having to run the whole
> > > compiler), and to strongly encourage patches to be accompanied by  
> > > unit
> > > tests.
> >
> > That's basically a pipe dream with the autoxxxx based build system.
>
> Actually the issues here are unrelated at all to auto* and unit  
> test framework.

So what do the words "full bootstrap/testing" mean, which you hear  
when providing
any kind of tinny fix? What about the involvement of those utilities  
through
zillions of command line defines and embedded shell scripting for  
code generation
on the ACUTAL code which makes up the gcc executables? Coverage? Unit  
testing?  How?!
Heck even just a full reliable symbol index for an editor isn't easy  
to come by...
Or are your just going to permute all possible configure options?

> The real reason why toplevel libgcc took years to come
> by is because nobody cared enough about libgcc to do any kind of  
> clean up.

Because there are actually not that many people who love to dvelve  
inside the
whole .m4 .guess and so on... Actually It's not that seldom that  
people are incapable
to reproduce the currently present build setup.

>   The attitude has
> changed recently (when I say recent I mean the last 3-4 years) to  
> all of these problems and
> in fact all major issues with GCC's build and internals are  
> changing for the better.

And now please compare this with the triviality of relocating source  
files in:

1. The FreeBSD bsdmake structure. (Which is pretty portable BTW.)
2. The solaris source tree.
3. A visual studio project.
4. xcode project.

> PS auto* is not to blame for GCC's problems, GCC is older than auto*.

It sure isn't the biggest problem by far. However it's the upfront  
one, if you
start to seriously look in to GCC. Remember - I'm the guy who  
compiles the whole
of GCC with C++, so it should be clear where I think the real issues  
are.