This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: build status page problem
- From: Janis Johnson <janis187 at us dot ibm dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Janis Johnson <janis187 at us dot ibm dot com>, Joe Buck <jbuck at synopsys dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 5 Dec 2001 10:55:07 -0800
- Subject: Re: build status page problem
- References: <janis187@us.ibm.com> <200112051821.NAA26124@makai.watson.ibm.com>
On Wed, Dec 05, 2001 at 01:21:45PM -0500, David Edelsohn wrote:
> >>>>> Janis Johnson writes:
>
> Janis> The assumption is that everything on the GCC 3.0 build status page
> Janis> builds with all releases of 3.0.x unless it says otherwise. So far
> Janis> there's only one note otherwise, for s390-linux-gnu which is supported
> Janis> beginning with 3.0.1.
>
> Janis> I'd prefer to keep that assumption. If there's a regression that
> Janis> prevents a target from building with a particular release we can add a
> Janis> note to that effect for that target.
>
> The problem is that we cannot tell from the page what reports we
> actually have received. If we have a report that some target worked with
> 3.0.1 but no report for 3.0.2, we cannot tell if it works and it may
> discourage someone from testing that new release and reporting the result.
>
> David
We don't get a flood of new reports for existing entries when a new
version of GCC is released, and I don't think that such reports would be
particularly useful. If there is an entry for a target and someone has
problems building it on some version of 3.0.x, then they should report
the problem, along with the fact that a successful build has been
reported.
Ideally, when a new release comes out people will build it and send in
their test results, which is more useful information than the build
status list. I see the build status list as initial information about
whether GCC 3.0.x is known to work on a particular target. There are
still a lot of variables that could prevent even the same version that
was reported from building on the same target with a slightly different
environment, so I hope that the existence of a target on the list
doesn't prevent new testing of it for new releases.
It would be useful to have a script similar to contrib/test_summary to
generate a message for reporting a successful build. Use of that script
would ensure that we get all of the relevant information in a report of
a successful build, including the configure flags to know whether all
languages were built, and versions of other relevant software on a
GNU/Linux system.
Janis