PROPOSAL: Alternate policy for obsoleting targets

PROPOSAL: Alternate policy for obsoleting targets

[Nathanael Nerode]

Here's a more modest proposal.

All target triples which are 'believed to work', at least somewhat, 
must be listed in the manual.  This will be done in the section for 
target-specific notes, which I hereby volunteer to rewrite and update. 
:-)

(I use the terminology 'believed to work' to avoid the word 'supported'.  
Better terminology is welcomed.)

It's perfectly OK for wildcard targets a la 'i[456789]86-*-*' to be in 
this list if we really believe that they work. :-)

After my first-pass rewrite (which will be based on config.gcc), I will 
call for people to volunteer targets which I left out, and targets on 
this list which actually aren't believed to work.  After a few cycles of 
this, and presumably before the release of 3.4, we'll have a 'complete list'.

Anything not on this list is immediately marked obsolete and removed.

Adding support for a target *requires* adding it to this list.

Removing support for a target *requires* removing it from this list.

--
Now for the actual obsolescence rule. :-)

Any target which has significant custom code (for instance, its own 
subdirectory or file under config/) requires a maintainer.  This is 
most of them.

Any such target without a maintainer is advertised as needing one.

If nobody steps up to the plate within 3 months, the target is obsoleted 
and then removed.

--Nathanael

Re: PROPOSAL: Alternate policy for obsoleting targets

[Gerald Pfeifer]

On Sun, 18 May 2003, Nathanael Nerode wrote:
> All target triples which are 'believed to work', at least somewhat,
> must be listed in the manual.

Fully agreed.

> This will be done in the section for target-specific notes, which I
> hereby volunteer to rewrite and update.  :-)

Thanks!

BTW, what really would be very useful IMSNHO is to make submitting
test results (and even build results without tests) easier.

Why can't we have

  make bootstrap
  make install
  make feedback

where the latter basically submits the configure options, or a

  make test

which automatically performs (documented, obviously!) what we currently
describe at the end of <http://gcc.gnu.org/install/test.html>?

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/