This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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