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


>>>>> "Janis" == Janis Johnson <janis187@us.ibm.com> writes:

 Janis> On Fri, May 16, 2003 at 12:33:50PM -0500, Joel Sherrill wrote:
 >> Peter Barada wrote:
 >> > 
 >> > > At the time GCC version 3.n is released, all targets which
 >> have not > > had a successful build and test report posted to
 >> gcc-testresults > > for prereleases of minor version n, or
 >> releases n-1 and n-2, go on > > the obsoletion list for version
 >> n+1.  "Successful" means minimum > > useful functionality: it's
 >> okay if only the C compiler works.
 >> > 
 >> > http://gcc.gnu.org/gcc-3.2/buildstat.html or >
 >> http://gcc.gnu.org/ml/gcc-testresults/2003-04/ only shows host >
 >> compilers, and no embedded targets(such as ppc-eabi, m68k-elf,
 >> etc).
 >> > 
 >> > How do we prevent embedded targets(that are know to work fine)
 >> from > from being placed on the obsoletion list?
 >> 
 Janis> [snip]
 >> This is why I try to report fairly regularly on targets I honestly
 >> don't use for real work. My thinking is that CPU-elf or CPU-coff
 >> is so close to CPU-rtems that any code generation problems are
 >> shared.
 >> 
 >> Importantly for embedded targets without simulators, it can be
 >> painful to even run the suite requiring some significant effort to
 >> setup.

 Janis> I might regret this, but I'm now willing to add cross build
 Janis> reports to the GCC build status lists.  If someone wants to
 Janis> suggest a list of what information such a report should
 Janis> include it could be linked from the beginning of the document.
 Janis> The list itself would probably just include something like

 Janis> <target triple> Cross build: 3.3

 Janis> where the "3.3" is a link to the archived message.  In
 Janis> previous discussions about listing cross builds in the status
 Janis> lists, I've assumed that I would need to pull relevant
 Janis> information out of the messages about the host, target, and
 Janis> possibly build machine, and put it all into the entry in some
 Janis> organized way.  If I can get away with merely adding
 Janis> simple-minded links, I no longer have objections to adding
 Janis> them to the list.

 Janis> It would be fine, by the way, for a report to include a long
 Janis> list of successful cross builds like the ones Joel does for
 Janis> RTEMS targets.

 Janis> So, back to the point of this thread: what kind of information
 Janis> would need to be included in reports of cross builds in order
 Janis> for those targets to be considered active?

I think what you describe is good.

My limited understanding of crossbuilds suggests that you can't
sensibly build gcc by itself, you have to build it along with other
stuff.  So capturing information about what else was built, including
what versions, would be useful.

Finally, since it appears that no one has time or energy to document
how crossbuilding works, would it be possible to ask cross-build
status reporters to make available, if possible, the scripts they use?
A pointer would be enough; copying it into the report is probably
excessive.  I'm thinking that perhaps I might be able to intuit what
the crossbuild process is from looking at a sufficiently large sample
of "scripts that just happen to work".  What the heck, I might as well
try, nothing else has worked...

     paul


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