PROPOSAL: Policy for obsoleting targets

PROPOSAL: Policy for obsoleting targets

[Zack Weinberg]

The last two times we've been round the release cycle, obsolete target
lists have been assembled ad-hoc.  I would post a list based on
intuitive impressions of what was no longer in use, then lots of
people would object to it and it would get pruned.

In the future I would like to do this more objectively.  To that end I
am proposing:

   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.

   At any time during the development cycle of version n+1, anyone can
   request the removal of a target from the obsoletion list, but they
   must first post a successful build and test report to gcc-testresults.
   Version n-2 is not acceptable anymore for this; it has to be n+1,
   n, or n-1.  If they needed to make changes to get the target to
   work, they must also post the patch to gcc-patches, but it does not
   have to get approved.

   When 3.(n+1) is released, the targets still on the obsoletion list
   are deleted from the mainline, and another sweep of gcc-testresults
   is made to establish the list for 3.(n+2).

We're in an unusual situation right now, because the 3.2 release
series came off the 3.1 release branch.  Therefore, for the 3.4
release I would count test results as far back as 3.1.0.  3.5,
however, will jump to 3.3 as the minimum.

Comments?

zw

Re: PROPOSAL: Policy for obsoleting targets

[Peter Barada]

>   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?

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: PROPOSAL: Policy for obsoleting targets

[Joel Sherrill]

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?

The m68k embedded targets (m68k-coff and m68k-elf) appear to both work
fine but have no test results reported in the mailing list archives.

I also have to point out that this would remove all *-rtems targets 
because we have to have an installed compiler to build RTEMS.  RTEMS
itself is a set of libraries that must be linked with the application
before being run on target hardware.  As of the last time I tried, the 
gcc test suite does not run on installed cross toolsets.  There is
something wrong with the scripts.  So I find the combination untestable.

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.

I decided to see how many targets which I thought had users would get
auto-deprecated by this policy.  Here is a quick take of targets 
which I did a search for in gcc-testresults.  <sarcasm on> I am pretty
sure 
that some of these have active users <sarcasm off>:

  *-vxworks - powerpc-vxworks is the only VxWorks target with 
              results reported and those are against 2.95.3 
              (20010125 prerelease).  
  *-vxwim      - No reports
  *-rtems      - No reports
  *-chorus*    - No reports
  *-lynx*      - No reports
  arm-ecos-elf - No reports
  avr*-*-*     - No reports
  m68k-coff    - No reports
  m68k-elf     - No reports
  m68k-atari-sysv4 - No reports
  *86-*-elf     - No reports
  *86-*-netware - No reports
  m68hc11*-*    - No reports
  m68hc12*-*    - No reports
  m88k*-*       - No reports
  pdp11*-*-*    - No reports
  xtensa*-*-*   - No reports
 
So that puts all VxWorks, RTEMS, ChorusOS, and LynxOS OS targets 
as well as the bare embedded m68k targets on the obsolete list.  What 
percentage of the embedded community does that cover?

I think this policy is probably OK for self-hosted environments but
raises the bar too high for embedded targets.  I fairly regularly 
report that at least the *-rtems and many of the embedded targets
without
simulators build.  I know what you are trying to achieve but this 
policy is too rough for embedded targets.

> --
> Peter Barada                                   Peter.Barada@motorola.com
> Wizard                                         781-852-2768 (direct)
> WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: PROPOSAL: Policy for obsoleting targets

[DJ Delorie]

> I think this policy is probably OK for self-hosted environments but
> raises the bar too high for embedded targets.

DJGPP is self-hosted but doesn't support expect, so we can't run the
testsuite either.

Re: PROPOSAL: Policy for obsoleting targets

[E. Weddington]

On 16 May 2003 at 12:33, Joel Sherrill wrote:

<snip>
> I decided to see how many targets which I thought had users would get
> auto-deprecated by this policy.  Here is a quick take of targets 
> which I did a search for in gcc-testresults.  <sarcasm on> I am pretty
> sure 
> that some of these have active users <sarcasm off>:
<snip> 
>   avr*-*-*     - No reports

I can attest that there have been over 9,000 downloads of the Windows hosted 
AVR cross alone. Then add in known AVR users on Linux and FreeBSD. The AVR 
target has an extremely active community.
 
> I think this policy is probably OK for self-hosted environments but
> raises the bar too high for embedded targets.  I fairly regularly 
> report that at least the *-rtems and many of the embedded targets
> without
> simulators build.  I know what you are trying to achieve but this 
> policy is too rough for embedded targets.

I would certainly agree.

Eric Weddington 

Re: PROPOSAL: Policy for obsoleting targets

[Joel Sherrill]

"E. Weddington" wrote:
> 
> On 16 May 2003 at 12:33, Joel Sherrill wrote:
> 
> <snip>
> > I decided to see how many targets which I thought had users would get
> > auto-deprecated by this policy.  Here is a quick take of targets
> > which I did a search for in gcc-testresults.  <sarcasm on> I am pretty
> > sure
> > that some of these have active users <sarcasm off>:
> <snip>
> >   avr*-*-*     - No reports
> 
> I can attest that there have been over 9,000 downloads of the Windows hosted
> AVR cross alone. Then add in known AVR users on Linux and FreeBSD. The AVR
> target has an extremely active community.
> 
> > I think this policy is probably OK for self-hosted environments but
> > raises the bar too high for embedded targets.  I fairly regularly
> > report that at least the *-rtems and many of the embedded targets
> > without
> > simulators build.  I know what you are trying to achieve but this
> > policy is too rough for embedded targets.
> 
> I would certainly agree.

I wish I was replying to the right post but someone mentioned that
a list of supported target triples would be nice.  I have to concur
on this one.  It is often not easy to find the magic triple that
binutils, gcc, newlib, and gdb agree on.

> Eric Weddington

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: PROPOSAL: Policy for obsoleting targets

[Janis Johnson]

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?
> 
  [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.

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.

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.

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?

Janis

Re: PROPOSAL: Policy for obsoleting targets

[Joel Sherrill]

Janis Johnson wrote:
> 
> 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?
> >
>   [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.
> 
> 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 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.
 
> 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. :)]

I try to report on about 30 embedded targets with a GNU/Linux host.  I
also have GNU/Linux -> Solaris and Cygwin cross compilers so I can 
Canadian cross builds for those.  Are the results of those builds 
important?  

> 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?

Personal opinion here.  A report target X builds on host Y is the
minimum.
The problem is that many people build crosses for a specific application
and if that works for them, that's all they care about.  

I would personally like to know that the target compiler could run
the testsuite (if a simulator in gdb is available).  If a simulator
is not available, then it would be wonderful to have a gcc test suite
setting/mode where you can do everything but run and have meaningful
results.  If we had this mode, then my periodic automated test builds
would give more information on targets like m68k and x86 embedded.

Another option would be a webpage that submits a record to a database of 
build information.  Then queries would be easier. But this is pie in 
the sky thinking.

> Janis

I don't want to make this a huge burden on you.  I know that proposals
in the past have done that.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: PROPOSAL: Policy for obsoleting targets

[Janis Johnson]

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

Re: PROPOSAL: Policy for obsoleting targets

[Paul Koning]

>>>>> "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

Re: PROPOSAL: Policy for obsoleting targets

[Joel Sherrill]

Paul Koning wrote:
> 
> >>>>> "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...

I have been waiting to wade in on the cross cookbook issue and 
now seems like the time.

The problem with cross build is that there is really no generic 
"build a cross compiler" procedure.  Based upon my experience,
I see a handful of patterns that have different procedures. 

  + cross to another host with binutils support
     - x86 GNU/Linux -> sparc-solaris or i386-cygwin
  + cross to a closed source host with no binutils support
      - x86 GNU/Linux -> ?? (remote shell to native as/ld)
  + cross to a bare embedded board using newlib
     - x86 GNU/Linux -> m68k-elf or arm-elf
  + cross to a bare embedded board using another C library
     - x86 GNU/Linux -> avr-elf
  + cross to another CPU's GNU/Linux
     - x86 GNU/Linux -> arm GNU/Linux
  + cross to a closed source RTOS
     - x86 GNU/Linux -> VxWorks or LynxOS
  + cross to an open source RTOS
     - x86 GNU/Linux -> RTEMS or eCos
  + ??? more

I used GNU/Linux as my example host because other hosts have their
own unique "features" for use in building tools.  Cygwin and
Solaris always seem to require special steps that GNU/Linux doesn't.
So the common problems like Cygwin CR/LF problems or Solaris 
not having a broken awk or sed have to be noted differently from the
procedure itself.

No one person is skilled in all those types of cross builds.  I have
done about 4 of them in the past year.  If GCC is to have good cross 
building instructions, then my proposal would be to divide the
instructions
into categories based upon the above patterns and any others that people
can identify.  

With the reduced scope on each category of cross, then the problem is 
more approachable.  And an option might be to get the experts in the
various types of crosses to submit their existing instructions.

>      paul

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: PROPOSAL: Policy for obsoleting targets

[Alexandre Oliva]

On May 16, 2003, Joel Sherrill <joel.sherrill@OARcorp.com> wrote:

> The problem with cross build is that there is really no generic 
> "build a cross compiler" procedure.

Excellent point.

> No one person is skilled in all those types of cross builds.  I have
> done about 4 of them in the past year.  If GCC is to have good cross
> building instructions, then my proposal would be to divide the
> instructions into categories based upon the above patterns and any
> others that people can identify.

Agreed on all counts.  You seem to have a great starting point.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: PROPOSAL: Policy for obsoleting targets

[Joe Buck]

On Fri, May 16, 2003 at 07:51:15PM -0300, Alexandre Oliva wrote:
> On May 16, 2003, Joel Sherrill <joel.sherrill@OARcorp.com> wrote:
> 
> > The problem with cross build is that there is really no generic 
> > "build a cross compiler" procedure.
> 
> Excellent point.
> 
> > No one person is skilled in all those types of cross builds.  I have
> > done about 4 of them in the past year.  If GCC is to have good cross
> > building instructions, then my proposal would be to divide the
> > instructions into categories based upon the above patterns and any
> > others that people can identify.
> 
> Agreed on all counts.  You seem to have a great starting point.

So, suppose we start a web page with Joel's categories as headings, and
then let people fill in sections for instructions in places where they
know the answer?  We'll wind up with missing sections, but at least we'll
have something to point people to.

Re: PROPOSAL: Policy for obsoleting targets

[Daniel Jacobowitz]

On Fri, May 16, 2003 at 04:54:54PM -0700, Joe Buck wrote:
> On Fri, May 16, 2003 at 07:51:15PM -0300, Alexandre Oliva wrote:
> > On May 16, 2003, Joel Sherrill <joel.sherrill@OARcorp.com> wrote:
> > 
> > > The problem with cross build is that there is really no generic 
> > > "build a cross compiler" procedure.
> > 
> > Excellent point.
> > 
> > > No one person is skilled in all those types of cross builds.  I have
> > > done about 4 of them in the past year.  If GCC is to have good cross
> > > building instructions, then my proposal would be to divide the
> > > instructions into categories based upon the above patterns and any
> > > others that people can identify.
> > 
> > Agreed on all counts.  You seem to have a great starting point.
> 
> So, suppose we start a web page with Joel's categories as headings, and
> then let people fill in sections for instructions in places where they
> know the answer?  We'll wind up with missing sections, but at least we'll
> have something to point people to.

This sounds like an extremely good idea.  (I may regret this but) I'll
volunteer to draft instructions for Linux targets based on the way we
do it here.  Probably other people will have other methods.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: PROPOSAL: Policy for obsoleting targets

[Jason Thorpe]

On Saturday, May 17, 2003, at 09:10  PM, Daniel Jacobowitz wrote:

> This sounds like an extremely good idea.  (I may regret this but) I'll
> volunteer to draft instructions for Linux targets based on the way we
> do it here.  Probably other people will have other methods.

I would be able to draft notes for NetBSD cross targets, as well.  The 
sysroot stuff sure makes it easy :-)

         -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: PROPOSAL: Policy for obsoleting targets

[Michael S. Zick]

On Friday 16 May 2003 06:54 pm, Joe Buck wrote:
> On Fri, May 16, 2003 at 07:51:15PM -0300, Alexandre Oliva wrote:
> > On May 16, 2003, Joel Sherrill <joel.sherrill@OARcorp.com> wrote:
> > > The problem with cross build is that there is really no generic
> > > "build a cross compiler" procedure.
> >
> > Excellent point.
> >
> > > No one person is skilled in all those types of cross builds.  I have
> > > done about 4 of them in the past year.  If GCC is to have good cross
> > > building instructions, then my proposal would be to divide the
> > > instructions into categories based upon the above patterns and any
> > > others that people can identify.
> >
> > Agreed on all counts.  You seem to have a great starting point.
>
> So, suppose we start a web page with Joel's categories as headings, and
> then let people fill in sections for instructions in places where they
> know the answer?  We'll wind up with missing sections, but at least we'll
> have something to point people to.
>
Perhaps establishing a Wiki would be the answer here.
It is such a diverse subject (cross-building) with many people having just
the bits and pieces that work for them; it sounds like an ideal subject for
a Wiki.

Re: PROPOSAL: Policy for obsoleting targets

[Dan Kegel]

Michael S.Zick wrote:
>>>>The problem with cross build is that there is really no generic
>>>>"build a cross compiler" procedure. ...
>>>
>>>>No one person is skilled in all those types of cross builds.  I have
>>>>done about 4 of them in the past year.  If GCC is to have good cross
>>>>building instructions, then my proposal would be to divide the
>>>>instructions into categories based upon the above patterns and any
>>>>others that people can identify.
>>>
>>>Agreed on all counts.  You seem to have a great starting point.
>>
>>So, suppose we start a web page with Joel's categories as headings, and
>>then let people fill in sections for instructions in places where they
>>know the answer?  We'll wind up with missing sections, but at least we'll
>>have something to point people to.
> 
> Perhaps establishing a Wiki would be the answer here.
> It is such a diverse subject (cross-building) with many people having just
> the bits and pieces that work for them; it sounds like an ideal subject for
> a Wiki.

Like, say, the one at http://billgatliff.com/twiki/bin/view/Crossgcc/WebHome ?
(though I don't much like wikis, and that one's a bit out of date...)

For what it's worth, over on the crossgcc mailing list, we're trying
to update Bill Gatliff's toolchain build script.
See also http://www.embeddedtux.org/pipermail/etux/2003-May/000018.html
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: PROPOSAL: Policy for obsoleting targets

[Joe Buck]

I wrote:
> >>So, suppose we start a web page with Joel's categories as headings, and
> >>then let people fill in sections for instructions in places where they
> >>know the answer?  We'll wind up with missing sections, but at least we'll
> >>have something to point people to.

Michael S.Zick wrote:
> > Perhaps establishing a Wiki would be the answer here.
> > It is such a diverse subject (cross-building) with many people having just
> > the bits and pieces that work for them; it sounds like an ideal subject for
> > a Wiki.

On Mon, May 19, 2003 at 05:08:43PM -0700, Dan Kegel wrote:
> Like, say, the one at http://billgatliff.com/twiki/bin/view/Crossgcc/WebHome ?
> (though I don't much like wikis, and that one's a bit out of date...)
> 
> For what it's worth, over on the crossgcc mailing list, we're trying
> to update Bill Gatliff's toolchain build script.
> See also http://www.embeddedtux.org/pipermail/etux/2003-May/000018.html

I don't object to wikis, but I'd prefer to wind up with an organized
document, that would document a flow that we'd then try to keep working
(at least for the common cases).

Re: PROPOSAL: Policy for obsoleting targets

[Ben Elliston]

Joe Buck <jbuck@synopsys.com> writes:

> So, suppose we start a web page with Joel's categories as headings,
> and then let people fill in sections for instructions in places
> where they know the answer?  We'll wind up with missing sections,
> but at least we'll have something to point people to.

IMHO, the material should go into the GCC installation manual.

Ben

Re: PROPOSAL: Policy for obsoleting targets

[Dan Kegel]

Ben Elliston wrote:
> Joe Buck <jbuck@synopsys.com> writes:
> 
> 
>>So, suppose we start a web page with Joel's categories as headings,
>>and then let people fill in sections for instructions in places
>>where they know the answer?  We'll wind up with missing sections,
>>but at least we'll have something to point people to.
> 
> 
> IMHO, the material should go into the GCC installation manual.

And IMHO it should be in executable form, so you can potentially
just run a script to get a working toolchain.  I'm trying to pull
together examples; so far, I have a canned script that downloads
sources and builds a working gcc/glibc/binutils for powerpc-linux
for gcc-3.2.3.  I'll try to do more.  They'll be at
http://www.kegel.com/crossgcc/
and are based on Bill Gatliff's work.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: PROPOSAL: Policy for obsoleting targets

[Michael S. Zick]

On Thursday 22 May 2003 12:09 am, Dan Kegel wrote:
> Ben Elliston wrote:
> > Joe Buck <jbuck@synopsys.com> writes:
> >>So, suppose we start a web page with Joel's categories as headings,
> >>and then let people fill in sections for instructions in places
> >>where they know the answer?  We'll wind up with missing sections,
> >>but at least we'll have something to point people to.
> >
> > IMHO, the material should go into the GCC installation manual.
>
> And IMHO it should be in executable form, so you can potentially
> just run a script to get a working toolchain.  I'm trying to pull
> together examples; so far, I have a canned script that downloads
> sources and builds a working gcc/glibc/binutils for powerpc-linux
> for gcc-3.2.3.  I'll try to do more.  They'll be at
> http://www.kegel.com/crossgcc/
> and are based on Bill Gatliff's work.
> - Dan
You might find useful ideas in this project:
  <http://automated.linuxfromscratch.org/>
Mike

Re: PROPOSAL: Policy for obsoleting targets

[Peter Barada]

>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...

I'd say that us cross-builders have generated *lots* of information on
what we have to go through to get a toolchain built.  Read though the
crossgcc list at http://sources.redhat.com/ml/crossgcc/ to get a
taste.

You'll find that everytime a release of binutils, gcc, newlib, glibc
comes out, we have to go back and sharpen our pencils again and try to
figure out a workaround for what's changed(such as the broken
--without-headers in gcc-3.x).

-- 
Peter Barada
peter@baradas.org

Re: PROPOSAL: Policy for obsoleting targets

[Paul Koning]

>>>>> "Peter" == Peter Barada <peter@baradas.org> writes:

 >> 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...

 Peter> I'd say that us cross-builders have generated *lots* of
 Peter> information on what we have to go through to get a toolchain
 Peter> built.  Read though the crossgcc list at
 Peter> http://sources.redhat.com/ml/crossgcc/ to get a taste.

I have... that's why I'm complaining.

This is the point -- there is no documentation, only a collection of
anecdotes, many of them years out of date.

 Peter> You'll find that everytime a release of binutils, gcc, newlib,
 Peter> glibc comes out, we have to go back and sharpen our pencils
 Peter> again and try to figure out a workaround for what's
 Peter> changed(such as the broken --without-headers in gcc-3.x).

Perhaps that's what happened -- I must have been trying to build
something that no one else tries, and since nothing follows any
pattern, none of the patterns were helpful.

	 paul

Re: PROPOSAL: Policy for obsoleting targets

[Joe Buck]

> In the future I would like to do this more objectively.  To that end I
> am proposing:
> 
>    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.

I'd have an issue with that, because there are many targets in active
use that we never seem to get any reports for.  The Debian folks are the
biggest example: they maintain about 11 different platforms and do
detailed bug tracking, yet we rarely get any reports from them.
In many cases they appear to do their own patches, if we break some port.

Now, I suppose if you want to threaten the Debian people with the loss of
their platforms, they might actually send us success reports.  But is that
the way we want to play?

Re: PROPOSAL: Policy for obsoleting targets

[Joseph S. Myers]

On Fri, 16 May 2003, Joe Buck wrote:

> I'd have an issue with that, because there are many targets in active
> use that we never seem to get any reports for.  The Debian folks are the

I would like to see the lists of:

* all supported target triples (preferably put them all in install.texi - 
even if there's no special information about the particular targets - so 
people can read that list to see what systems are supported and to know 
the available target triples when configuring for an embedded system - and 
then remove the old list of systems in install-old.texi);

* the target triples for which testresults have been received, according
to the proposed system;

* the target triples for which no testresults have been received; both of
these lists being marked according to whether they are hosted systems.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: PROPOSAL: Policy for obsoleting targets

[Joe Buck]

On Fri, May 16, 2003 at 06:04:41PM +0100, Joseph S. Myers wrote:
> I would like to see the lists of:
> 
> * all supported target triples (preferably put them all in install.texi - 

The list would be empty, since we do not provide support as it is
traditionally understood for any platform.  We should be careful to avoid
this word.

If you want to replace it by a list of *tested* target triples, that's
fine.  Or we could list the primary and secondary platforms.

> * the target triples for which testresults have been received, according
> to the proposed system;

Whoops, you list this separately, so it seems you do believe that there is
something that we support.

> * the target triples for which no testresults have been received; both of
> these lists being marked according to whether they are hosted systems.

How can we generate this list?  config.guess will generate an arbitrarily
large list of target triples, including identifiers for OS revisions that
didn't exist at the time the compiler shipped.

Re: PROPOSAL: Policy for obsoleting targets

[Joseph S. Myers]

On Fri, 16 May 2003, Joe Buck wrote:

> On Fri, May 16, 2003 at 06:04:41PM +0100, Joseph S. Myers wrote:
> > I would like to see the lists of:
> > 
> > * all supported target triples (preferably put them all in install.texi - 
> 
> The list would be empty, since we do not provide support as it is
> traditionally understood for any platform.  We should be careful to avoid
> this word.
> 
> If you want to replace it by a list of *tested* target triples, that's
> fine.  Or we could list the primary and secondary platforms.

I refer to the (equivalence classes of) target triples for which
configuration files and code in config.gcc to use them are present.  At
present, we have a partial list in install.texi (install/specific.html) of
systems with specific notes and some others where it is just described
what the target triple means, and old lists on install-old.texi of once
known values of CPU, company and system, and machine aliases; I suggest
that the list in install.texi should include all target triples (with for
each at least a text statement of what system is meant) so that the lists
in install-old.texi are fully obsoleted and can be removed.

Kaveh has had such a list derived from config.gcc in the past (e.g.  
<http://gcc.gnu.org/ml/gcc-patches/2001-11/msg00188.html> - of course that
particular list is very out of date by now).

> > * the target triples for which no testresults have been received; both of
> > these lists being marked according to whether they are hosted systems.
> 
> How can we generate this list?  config.guess will generate an arbitrarily
> large list of target triples, including identifiers for OS revisions that
> didn't exist at the time the compiler shipped.

The first list minus the second list; made finite by considering
equivalence classes of configurations, as noted above; hopefully there is
no code in GCC depending on the particular configured future version of an
OS.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: PROPOSAL: Policy for obsoleting targets

[Jason Thorpe]

On Friday, May 16, 2003, at 01:55  PM, Joe Buck wrote:

> The list would be empty, since we do not provide support as it is
> traditionally understood for any platform.  We should be careful to 
> avoid
> this word.

I think by "supported" he means "which the configury specifically 
matches", i.e. triples which you can actually pass in a --target=... 
switch.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: PROPOSAL: Policy for obsoleting targets

[Michael S. Zick]

On Wednesday 21 May 2003 11:32 am, Jason Thorpe wrote:
> On Friday, May 16, 2003, at 01:55  PM, Joe Buck wrote:
> > The list would be empty, since we do not provide support as it is
> > traditionally understood for any platform.  We should be careful to
> > avoid
> > this word.
>
> I think by "supported" he means "which the configury specifically
> matches", i.e. triples which you can actually pass in a --target=...
> switch.
>
>          -- Jason R. Thorpe <thorpej@wasabisystems.com>
As in: "A recognized target..." ?

Re: PROPOSAL: Policy for obsoleting targets

[Daniel Jacobowitz]

On Fri, May 16, 2003 at 09:34:57AM -0700, Joe Buck wrote:
> 
> > In the future I would like to do this more objectively.  To that end I
> > am proposing:
> > 
> >    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.
> 
> I'd have an issue with that, because there are many targets in active
> use that we never seem to get any reports for.  The Debian folks are the
> biggest example: they maintain about 11 different platforms and do
> detailed bug tracking, yet we rarely get any reports from them.
> In many cases they appear to do their own patches, if we break some port.
> 
> Now, I suppose if you want to threaten the Debian people with the loss of
> their platforms, they might actually send us success reports.  But is that
> the way we want to play?

Eh?  Matthias sends in test results from Debian GCC packages routinely,
especially during releases.  I see maybe a dozen every week go by.  And
we forward relevant bugs to GNATS on a regular basis.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: PROPOSAL: Policy for obsoleting targets

[Jan Vroonhof]

Zack Weinberg <zack@codesourcery.com> writes:

> In the future I would like to do this more objectively.  To that end I
> am proposing:
>
>    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.

Personally I think this far too aggressive. Just from what compilers I
come across during my work and hobbies the adoption rate is much lower than 
this schedule suggest.

In practice people went

2.9.3
egcs 1.1
gcc 2.95
possibly some 2.96/2.97 hack
gcc 3.2

Note the absence of any work with 3.0. Even the x86-Linux
distributions did that and that are probably the most important target
nowadays.

This is not entirely due to inertia. One should just accept that GCC
releases have been of varying quality. Especially from an Embedded
point of view gcc 3.2 is 2.95.3's real successor and not 3.0. I still
see more projects using 2.95.x then 3.x!

So I would like to see

1.  The above process modified to not use version numbers directly but
where the steps are releases that have obviously high adoptions rates.

2. The process in step 1 only marks them as "obsoletable". I don't see
why wholesale removal of target stuff is doing much good if the target
isn't really increasing general maintenance costs by requiring other
unnecessary features of the shared code. Surely there are lots of
targets that sit happily in their little corner with a few files and
can easily be kept up to date by grep, sed and friends. They might rot
a bit, maybe even stop building, but resurrecting them is a lot easier
than starting from scratch.

Just my 2p.

Jan

Re: PROPOSAL: Policy for obsoleting targets

[Marc Espie]

In article <874r3u27sm.fsf@egil.codesourcery.com> you write:
>
>The last two times we've been round the release cycle, obsolete target
>lists have been assembled ad-hoc.  I would post a list based on
>intuitive impressions of what was no longer in use, then lots of
>people would object to it and it would get pruned.
>
>In the future I would like to do this more objectively.  To that end I
>am proposing:
>
>   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.
>
>   At any time during the development cycle of version n+1, anyone can
>   request the removal of a target from the obsoletion list, but they
>   must first post a successful build and test report to gcc-testresults.

I'm completely against this.

For various reasons, me and other OpenBSD folks tend to lag behind gcc
releases quite a bit. For instance, having the compiler slowing down more
and more doesn't help.  Plus, we have other changes to test that very
often conflict with gcc issues.

We also have totally different release schedules and demands compared to
the gcc mainlines.

If you look closely at recent gcc releases, you might be surprised to
discover that almost *none* of them build cleanly on any OpenBSD systems.
However, this doesn't prevent us from having a functional port of gcc 3.2
(soon to be updated to gcc 3.3, now that the i386 switch to elf is complete),
and to have various running targets, including vax and hppa ports (that
currently use gcc 2.95.x, but gcc 3.2/3.3 has been somewhat tested since).

Simply put, we don't have the manpower, nor the energy, to follow test
results very carefully.  Writing patches that will be accepted by the SC
is often tedious, or downright impossible, because of conflicting policies.
It's also one small item in our busy agenda (I'm probably the chief OpenBSD
contributor to gcc of late, but by no means the only person working on it...
but gcc is definitely not the only thing I'm working on).

So, your `automated' policy will very likely put most OpenBSD platform on
the obsoletion list very quickly, even though those are quite alive and
kicking.

Re: PROPOSAL: Policy for obsoleting targets

[Joe Buck]

On Sun, May 18, 2003 at 04:17:37PM +0200, Marc Espie wrote:
> Simply put, we don't have the manpower, nor the energy, to follow test
> results very carefully.  Writing patches that will be accepted by the SC

The SC does not involve itself in the approval of patches, and gives
port maintainers a free hand in applying patches that only affect a
particular target.

> So, your `automated' policy will very likely put most OpenBSD platform on
> the obsoletion list very quickly, even though those are quite alive and
> kicking.

The SC is not going to approve any policy change that would permit widely
used platforms to be deprecated.

Re: PROPOSAL: Policy for obsoleting targets

[Jason Thorpe]

[ I apologize .. I'm finally catching up on GCC mail, having not had 
the time to read
   it for a about a month .. ]

On Sunday, May 18, 2003, at 07:17  AM, Marc Espie wrote:

> I'm completely against this.

I'll agree with Marc, here.

NetBSD is in a situation where we were at 2.95 for quite a long time 
for various stupid reasons (mainly "no one willing to get 
NetBSD-specific fixes into GCC mainline" for a long time ... until I 
stepped up to the task, for better or worse :-)

GCC 3.3 is the first GCC release in a VERY long time which supports the 
majority of NetBSD's supported platforms out-of-box, so you're 
certainly not going to see 3.x test results before 3.3 that cover a 
wide range of NetBSD targets.

There are other issues with testing, as well... NetBSD runs on quite a 
number of platforms, many of which are hard to find, are extremely 
slow, or consume way too much power for anyone to want to power it up 
for any length of time.  Considering how piggish GCC has become in 
terms of compile speed, it takes a REALLY long time to bootstrap on my 
HP 9000/380, only to find out at the end of a couple of days that 
libstdc++ failed to compile due to an assembler bug.

Here are what I see as some gaps in GCC testing support:

	1. There does not appear to be a pre-packaged "automated regression 
testing kit"
	   in the source tree.  For people with a limited amount of time, 
setting one up
	   can be an obstacle.  If there were a nice set of scripts and 
concise instructions
	   on how to set them up and use them, this would be a big help.

	2. It does not appear as if the testsuite is run in rsh mode very 
often.  Because
	   I have a number of slow targets to support, I really like to run 
the testsuite on
	   a host, and use the rsh method to run execute tests on the target.  
However, I
	   have run into problems with some of the tests in this type of 
configuration, and
	   I have little time to actually track them down at the moment.

	   Obviously, if the scripts mentioned in (1) supported a 
host-rsh-target setup,
	   that'd be extra cool :-)

	3. GCC's compile-time performance is so bad that it causes testsuite 
failures on
	   some platforms simply because dejagnu gives up waiting for the 
compiler to
	   finish.  I have not been able to run the testsuite on an SS20 for 
quite a long
	   time.  There's really no excuse for that.

Anyway, these three things would certainly help me provide more regular 
NetBSD test results, and would make it *possible* for me to report on 
more platforms than x86, alpha, and mipseb.

         -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: PROPOSAL: Policy for obsoleting targets

[Dan Kegel]

Jason Thorpe wrote:

> 2. It does not appear as if the testsuite is run in rsh mode very often.
> Because I have a number of slow targets to support, I really like to run
> the testsuite on a host, and use the rsh method to run execute tests on
> the target.  However, I have run into problems with some of the tests
> in this type of configuration, and I have little time to actually track
> them down at the moment.
> 
> Obviously, if the scripts mentioned in (1) supported a host-rsh-target
> setup, that'd be extra cool :-)

Hear, hear!  I'm going to be trying this again shortly.

BTW my impression is that rsh itself is a bit hard to get working these days.
I hacked up an rshd.c for embedded machines to remove all security;
that makes it a bit easier to get up and running.  (Don't try this
when connected to the internet, of course...)
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: PROPOSAL: Policy for obsoleting targets

[Zack Weinberg]

The discussion in response to this proposal has been interesting.  It
seems that it was too radical, at least for the present time.  I would
like to make a few observations in defense of it, or at least a
similar plan, however.

One class of objections to the original proposal centers around its
being difficult or impossible to run the test suite against some
otherwise supported targets.  This is a serious problem in its own
right.  It can be partially addressed through documentation, and it
sounds like people are making plans to improve the documentation.  I
know a fair bit about building cross-toolchains, and will gladly lend
a hand there.  However, at least right now it sounds like a
requirement to run the testsuite is too strong.  I have no problem
with weakening the requirement there; perhaps a simple report of some
kind of successful build could suffice.

Another class of objections centers around there being targets which
are maintained, but not in the FSF's repository, and with little or no
communication between us and the people doing the maintenance.  First,
I'd argue that if GCC isn't usable out of the box on a major free
operating system, there's another serious problem right there (and,
again, I'm willing to help resolve it).  Second, yes, my proposal
would make these targets go away if something didn't change, but
please realize that the necessary effort to keep a target around is as
minimal as I think it is feasible to make it.  No more often than once
every six months, someone would have to try to build our source tree,
report that it works, and send us any necessary patches.  Note that I
did *not* say the patches have to get applied.  My suspicion is that
the alternate proposals which were kicking around would actually be
*more* burdensome on these people.

Someone asked why we want to get rid of targets which still work,
whether or not anyone is using them.  The answer is that, in the
present state of the GCC source tree, each unused target presents
an additional burden to maintainers of the common portions of GCC.
We are trying to clean up the back-end interface so that it has not
got tentacles into every last source file of the allegedly machine-
independent compiler.  This requires modifying all the targets.  It
is *not* simply a matter of "keeping them up to date with sed."
I've done a lot of this work, and the changes required have never
been that automated.

Furthermore, the changes that someone doing a global sweep makes are
never as thorough as they should be.  As an example, the VxWorks ports
languished for several years until Nathan and I took them over.  My
first act was to throw away every line of existing support code and
start from scratch.  It was easier to do that than to update them
piecemeal.  Then we left the new port alone for six months; when we
came back to it it had *already* decayed to the point where I had to
rewrite the whole of config/rs6000/vxworks.h, albeit not the entire
port.  (This work hasn't made it into the FSF's tree yet, but will
soon.)  The people who updated it in the interim were conscientious,
but they naturally did the minimum, and that still left the port well
behind the curve.  Because of this experience, I feel that keeping old
unused ports around is a disservice even to hypothetical future people
who want that old port.  They're going to wind up throwing it all away
anyway, and all the effort put into keeping that port nominally up to
date will have been wasted.

zw

Re: PROPOSAL: Policy for obsoleting targets

[Michael S. Zick]

On Tuesday 20 May 2003 11:55 pm, Zack Weinberg wrote:
> The discussion in response to this proposal has been interesting.  It
> seems that it was too radical, at least for the present time.  I would
> like to make a few observations in defense of it, or at least a
> similar plan, however.
>
- - snip - -
>
> Because of this experience, I feel that keeping old
> unused ports around is a disservice even to hypothetical future people
> who want that old port.  They're going to wind up throwing it all away
> anyway, and all the effort put into keeping that port nominally up to
> date will have been wasted.
>
Could a new listing be added to the Web pages that showed:
"Target Triple" -> "Last reported, working release"
"Target Triple" -> "Last known update"
"Target Triple" -> "Dropped in release: x.y.z"

That would be information for people returning to the use of gcc
after the target they where interested in had disappeared. 
That page might also be included with the release tar-ball.  I can
imgine that people would not look for that information until the release
they just downloaded didn't work for their target.

Could the policy for obsoleting targets measure the passage of
time in "Releases since last reported working" rather than in
months?

Mike
> zw

Re: PROPOSAL: Policy for obsoleting targets

[Dan Kegel]

Zack Weinberg wrote:
> One class of objections to the original proposal centers around its
> being difficult or impossible to run the test suite against some
> otherwise supported targets.  This is a serious problem in its own
> right.  It can be partially addressed through documentation, and it
> sounds like people are making plans to improve the documentation.  I
> know a fair bit about building cross-toolchains, and will gladly lend
> a hand there.

I'm interested in helping, too.   I have already helped out a bit
on dejagnu documentation.  Still haven't managed to run a remote
test using it, though.

It's interesting that expect is a stumbling block for the djgpp port.
Perhaps a batch mode version of the framework could be put together
that did all the compiles in one pass, and all the runs in a second
pass, controlled by a script rather than by expect.
The farther away we can get from dejagnu the better, IMHO.
It's extremely difficult to understand and use in a remote environment.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: PROPOSAL: Policy for obsoleting targets

[Karim Yaghmour]

[Please CC me in any replies as I'm not subscribed to the gcc mailing
list.]

Joel Sherrill wrote:
> With the reduced scope on each category of cross, then the problem is 
> more approachable.  And an option might be to get the experts in the
> various types of crosses to submit their existing instructions.

For those who are interested, I provide a full ~30 page instructions
on how to build a cross toolchain for Linux targets from scratch in
my book:
http://www.oreilly.com/catalog/belinuxsys/

I've also set up a table for providing up-to-date toolchain component
version combinations:
http://www.embeddedtux.org/gnu-tools.html

If you have any version combinations to submit, feel free to send them
to the embeddedTUX.org mailing list for others to review. The table
of combinations will be updated accordingly.

Cheers,

Karim

===================================================
                 Karim Yaghmour
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================