Re: Reverting r2000 for gcc-4.2
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
Reply to: