[oe] [RFC] Toolchain recipes, versions, removal and consolidation

[Tom Rini]

Khem Raj wrote:
> Hi
> 
> There are so many versions of toolchain components gcc/binutils/glibc that
> we have in metadata. I would like to reduce the number and keep supporting
> the ones we really use. Right now we have recipes for
> 
> binutils = 2.14.90.0.6,2.14.90.0.7, 2.15.94.0.1, 2.16, 2.16.1, 2.16.91.0.6,
> 2.16.91.0.7, 2.17, 2.17.50.1, 2.17.50.0.5, 2.17.50.0.8, 2.17.50.0.12, 2.18,
> 2.18.50.0.7, 2.18.atmel.1.0.1, 2.19, 2.19.1, 2.19.51, 2.19.51.0.3, 2.20,
> 2.20.1, cvs
> 
> gcc = 3.3.3, 3.3.4, 3.4.3, 3.4.4, 3.4.6, 4.0.0, 4.0.2, 4.1.0, 4.1.1, 4.1.2,
> 4.2.1, 4.2.2, 4.2.3, 4.2.4, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.4.1, 4.4.2,
> 4.4.4, 4.5, csl-arm-2007q3, csl-arm-2008q1, csl-arm-2008q3
> 
> glibc = 2.2.5, 2.3.2, 2.3.3, 2.3.5+cvs20050627, 2.5, 2.6.1, 2.9, 2.10.1,
> cvs
> 
> uclibc = 0.9.28, 0.9.29, 0.9.30, 0.9.30.1, 0.9.30.2, 0.9.30.3, 0.9.31, git
> 
> 
> eglibc = 2.9, 2.10, 2.11, 2.12, svn

For flexibility in out of tree projects, I'd like to see us keep at 
least for binutils 2.18 and newer (official releases) and one each of 
the H.J. Lu releases (.5x.y.z) for folks that need that.  Similarly for 
gcc, 4.2.4, 4.3.4, 4.4.4 and one of the csl's.  For glibc, 2.9 and 
newer?  For uclibc maybe we can drop 0.9.30.[12] if they aren't pinned.

But I fear this won't help your concern as much since often fixing up 
for say gcc 4.2.4 fixes it up for 4.2.1 and 4.2.2 and 4.2.3, and so forth.

-- 
Tom Rini
Mentor Graphics Corporation