[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> 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

> 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.


Reply to: