redundancies to prune from the results matrix?

["Robert P. J. Day" <rpjday at mindspring dot com>]

  i'm hoping someone can clarify something for me regarding the
entries in the crosstool matrix at:

  http://kegel.com/crosstool/crosstool-0.43/buildlogs/

given the numerous combinations in that table, at what point can you
consider one combination to have been superseded or obsoleted by
another?

  for example, let's say i can build a toolchain with gcc-4.0.2 and a
bunch of other components.  i then find out i can build an equally
functional toolchain with exactly the same components except with
gcc-4.0.3.  is there any point recording that gcc-4.0.2 works once i
have gcc-4.0.3 working equally well (all other things being equal)?

  of course, i appreciate that it's potentially useful to have every
single combination recorded but, once the table gets that huge, is
there some categorization that lets us say that combination "A" is
effectively subsumed by combination "B" *if* they both appear to have
precisely the same functionality?

  more to the point, is there any value in recording that some
combination *fails* to build if a slightly newer combination
*succeeds*?  thoughts?

rday

p.s.  as a concrete example, as i've mentioned before, i've built what
appears to be a functioning x86_64 toolchain with the following
combination:

	gcc-4.0.4
	glibc-2.3.6
	binutils-2.17
	linux-2.6.15.4
	linux-libc-headers-2.6.12.0
	gdb-6.6

i've used the result to cross-compile the kernel, and install and
reboot on an x86_64 system, so i've verified that that toolchain
appears to be robust enough to compile a functional kernel.

once i've established that that appears to be a working combination
for x86_64, if someone *else* wanted to build an x86-64 toolchain, why
would they spend a lot of time looking for other possible working
combinations once i've given them one?  what value would they get out
of knowing that earlier combinations have problems?

p.p.s.  let me throw out another idea -- there should be, somewhere,
the results of trying to build a toolchain for every possible
architecture with the absolute *latest* available combination of
software components.  i think it would be an informative benchmark to
see how well (or how badly) builds go with the leading edge stuff.

even if every single one of those builds fail, that would still be
nice to know.

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

--
For unsubscribe information see http://sourceware.org/lists.html#faq