This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets
- From: Bruce Korb <bkorb at veritas dot com>
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: Joe Buck <jbuck at synopsys dot com>, DJ Delorie <dj at redhat dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 20 May 2003 11:19:34 -0700
- Subject: Re: PROPOSAL: Variation on an Alternate policy for obsoleting targets
- References: <3ECA6C2D.70B1169C@superh.com>
- Reply-to: bkorb at veritas dot com
Joern Rennecke wrote:
>
> Bruce Korb wrote:
> > Would it be too much trouble to set an environment variable
> > and email in the resulting report file? (Were it implemented.)
> [Would] the report be large?
It would contain one line for every fix that got triggered,
whether for one header or many headers. Most platforms would
have under a dozen lines, plus some introductory overhead and
the config.guess output. I could jigger it to include other
stuff for bug reporting, if that were considered useful.
> If not, it might be useful to have
> it produced by default, for debugging purposes when something
> goes awry.
> And we could change the instructions how to report a
> successful build so that people just have to grab this file
> and mail it to a specified address. Considering how hard it
> is for some people to report the output of config.guess (we've
> gotten some copies of config.guess instead) it might be safer to
> quote a filename of a file that is only generated by a build.
A build info file, of sorts. Sure. Define such a file and let
any part of the build add useful information, as long as the
size were kept "reasonable" and you figured out how to handle
parallel builds.