For the past few hours I’ve been going a build of the GCC packages on a dual-core Opteron system with 2.5G of RAM and a pair of reasonably fast SATA disks in a RAID-1 array. The machine is reasonably powerful so presumably such a build would take a significantly larger amount of time on a laptop or an older machine – my primary development machine is an old laptop and is thus unsuitable for such things.
My aim is to do a build with the patch for GCC bug 40518 [1] – which is a small patch to the STL.
Presumably the people who are seriously involved in GCC development don’t do this, they would be doing a build of a small sub-set that matches the code that they are working on. But as someone who is not involved in the project such an approach doesn’t seem viable, by using the Debian build tools to rebuild all packages from the source package I can reliably get a good build.
It would be convenient if these large source packages could be split into smaller packages. It shouldn’t be necessary to compile the C compiler (presumably with the full double-compile process), as well as the C++, Objective C, and Fortran compilers when I only want to compile the STL (libstdc++). It also shouldn’t be necessary for me to hack around a build system when all I want to do is to apply and test a single patch.
It seems to me that the current situation discourages contributions. If I can build a package in a reasonable amount of time on my laptop (Pentium-M 1.7GHz with 1.5G of RAM) then I can work on it at any time and in any place. If it requires hours of build time on my biggest machine then I can only work on it when at home and only when I have hours to spare (or if I have enough of a need to come back to it the next day).
So if there are two bugs that have equal importance to me and one of them happens to be in part of the GCC family then the probability that I will work on the GCC bug is close to zero.
I realise that packaging GCC etc is really hard work. But it seems that making it easier for more people to contribute would alleviate the burden slightly.
I think, where possible, it would be nice to have some standard procedure in Debian packages with 1:many source:binary targets where you can do subset-builds when you are only interested in testing one of the binary outputs. Also a way of separating out the build-dependencies for the various binary targets. Apart from GCC, apps with large documentation and huge documentation toolchain dependencies come to mind.
Jon: That’s an interesting concept. The problem is that probably very few source packages which have multiple binary packages would be set up for this (IE having split dependencies for the different parts). It could be solved but I’m not sure how much traction it would get with the DDs.
Really this sort of thing needs to be done upstream.
I use –disable-dootstrap when I only want to build and test libstdc++ rather than bootstrap the C compiler.
There is no reason why you should build the ObjC and Fortran compilers, just use –enable-languages=c,c++
Oops, that should be -–disable-bootstrap not dootstrap!
Hi Russell,
As shipped by upstream, GCC is available in smaller packages. If you’re just interested in patching libstdc++, you’d only need to download the gcc-core and gcc-g++ pieces, and you can skip the most time-consuming step (building Java and its libraries).
However, the pieces that add on to gcc-core don’t correspond to independent source packages in the sense of dpkg or rpm.