This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PROPOSAL: Policy for obsoleting targets


On Fri, May 16, 2003 at 05:09:43PM -0500, Joel Sherrill wrote:
> Janis Johnson wrote:
> > 
> > I might regret this, but I'm now willing to add cross build reports to
> > the GCC build status lists.  If someone wants to suggest a list of what
> > information such a report should include it could be linked from the
> > beginning of the document.  The list itself would probably just include
> > something like
> > 
> >   <target triple>                   Cross build: 3.3
> > 
> > where the "3.3" is a link to the archived message.  In previous
> > discussions about listing cross builds in the status lists, I've
> > assumed that I would need to pull relevant information out of the
> > messages about the host, target, and possibly build machine, and put
> > it all into the entry in some organized way.  If I can get away with
> > merely adding simple-minded links, I no longer have objections to
> > adding them to the list.
> 
> How would you deal with multiple people reporting on the same build?
> It is really nice to see at least target and host but I know that
> is work on your side. So I would like to see 3 columns: target, host,
> and gcc version.

The first column would be the target triple and the third column would
be a list of links to build reports and/or test results, just like the
current third column for bootstraps.  Instead of "Successful" before the
build list I've started using "Bootstrap", and would use "Cross build"
for cross builds.  If there are multiple reports for a target, they all
get links.  The second column can start out being just the host, but if
it's easy and makes sense, other information can go there as well.  If
there needs to be different information in the second column for
different builds then I'd just split them into multiple entries as I do
now.  The format will evolve over time if need be.

> The linked to message should include more information like binutils
> version, C library, configure command, and did the test suite get run.
> If there is a patch or hack needed to build it, hopefully that will
> get included in the writeup.

Yes, and people reporting builds should always include any information
that they think might be useful to other people doing the same build.
  
> > It would be fine, by the way, for a report to include a long list
> > of successful cross builds like the ones Joel does for RTEMS targets.
> 
> I generate the summary reports because it is easier for me.  Would it
> be better to generate one message per target?  [Hoping you say no. :)]

Combined reports are actually slightly easier to add to the list just
because the URL only needs to be found one time.  It should be clear at
the top of the report that it includes more than one build, but people
generally do that already.
 
> > So, back to the point of this thread: what kind of information would
> > need to be included in reports of cross builds in order for those
> > targets to be considered active?
> 
> I don't want to make this a huge burden on you.  I know that proposals
> in the past have done that.

My goal for the build status lists has become making it as easy as
possible to keep them updated; someone wanting information from them
probably doesn't mind doing a little bit of searching.

You brought up other good issues, too, that I haven't addressed here.

Janis


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]