Peter Slegg wrote:
Is there anything we can do that will minimise the amount of work needed when the next release of GCC emerges ?
The master word is: automationFor every package, we should have a source package and a rock-solid build script for building the binary package (it may be already the case for the source RPMs - sorry for my ignorance). Then the build farm proposed by Mark should be able to rebuild everything automatically ! New releases of GCC are out every 2-3 monthes. The patches are usually very easy to port from a version to the next one, so when an official release of GCC is available, we could reasonably expect to have a MiNT patch a week after.
Note that GCC 4 is more strict than the other versions. Very often, older code has to be patched a bit in order to be compilable. Of course, all the new versions of the GNU software are ready for GCC 4. But older software may have to be checked.
That's why the current GCC binaries (native or cross) are useful: even if they are not 100% perfect right now, they can be used to check the compilation problems, and the sources can be patched. So when the "official" version will be out, everything will compile immediately !
If a lot of RPMs are to be updated with GCC 4 should they be on a separate Sparemint page or is this not necessary ? What I mean is, if a package is updated will it be ok to install with older stuff.
There are 2 cases:- The programs: no compatibility issue. As soon a package is updated, anyone can use it for first installation or upgrade - The libraries: all of them will probably have to be updated every time the compiler is updated. We may manage to get some compatibility with the C libraries, but I don't think it will be possible with C++ ones (but they are not a lot).
It would be really nice if we could keep the most important tools up to date !
-- Vincent Rivière