This is the mail archive of the
mailing list for the GCC project.
Re: PATCH RFA: Do not build java by default
- From: Laurent GUERBY <laurent at guerby dot net>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Ian Lance Taylor <iant at google dot com>, gcc at gcc dot gnu dot org, java at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Tue, 02 Nov 2010 11:13:49 +0100
- Subject: Re: PATCH RFA: Do not build java by default
- References: <email@example.com> <4CCE817D.firstname.lastname@example.org>
On Mon, 2010-11-01 at 08:59 +0000, Andrew Haley wrote:
> On 10/31/2010 07:09 PM, Ian Lance Taylor wrote:
> > This patch should not of course change whether or not distros choose to
> > package the Java compiler; undoubtedly they would continue to do so,
> > just as they package the Ada compiler today.
> > Comments? Approvals?
> I see your point, but this will lead to some quality regressions in gcc
> itself. libgcj is a good stress test for gcc, and has revealed some
> bugs in the past. It might be possible to mitigate some of this with
> autotesters that run a full libgcj bootstrap every night.
Let's imagine we have a reliable tool on a distributed build farm that
accepts set of patches (via mail and web with some authentification) and
does automatic regression testing and report on selected platform.
This would enable more ambitious in our testing requirements without
having developpers invest in powerful machines to avoid being slowed
down but would GCC developpers go as far as setting a requirement that
patches must be validated by such a tool before commit for example by
giving the URL of the tester result with suitable exceptions for trivial
patches and tester being unavailable or overloaded, etc...?