Ludovic Brenta writes: > Matthias Klose writes: > > I'll revert this checkin on the 4.2 branch. Without it we only apply > > and test the patches for specific builds and architectures. This > > then tends to be discovered on the build daemons, which is late. > > Adjusting the build dependencies is certainly ok. > > OK, that's why this was a separate commit. For the > architecture-specific patches, you are probably right, but for the > language-specific ones, we always build gcc, gcj and gnat manually > before an upload, so we would discover any patch that no longer > applies cleanly.
but not if you are working with the gcc-4.2 source. with your approach I need to build gcj-4.1 and gnat-4.1 as well to discover patch failures. > Another concern of mine is that patches for one > language might interfere with patches for another (e.g. if they touch > the top-level configure or Makefile.in). Applying only the minimal > set of patches was meant to reduce that risk. you loose the ability to build all languages from one source, if you introduce such conflicting patches. > Finally, on some > machines like my old IBM ThinkPad T22, it takes > 10 minutes just to > apply all the patches, especially the Java ones. I didn't see that in 4.2; 4.1 had the libjava backport, but this is gone. > Now I'm not so > concerned anymore for myself since I build in a 1 Gb ramdisk, but this > is a barrier for entry for other people who may want to contribute. well, this is a generic argument for large source packages. shipping unpacked sources increases the time to build the diff.gz, shipping tarballs adds a bit more to unpack the tarballs. it's a tradeoff. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
