Remaining host configuration fragments

[Joe Buck]

Kenner writes:
>     IMHO a platform should be deprecated iff it meets all these:
> 
>     1. Platform not supported by manufacturer for N years
>     2. No volunteers to maintain the port
>     3. Known not to function for the last N minor releases (2.95, 3.0, 3.1)
>     4. Nobody notices #3 :-)
> 
> Of course, if #4 is true, the first part of #3 can't be, but basically
> I agree with a very strict criteria like this.

I like the general thrust of this proposal.

To make it consistent, just change #4 to "There are no users of the
platform who have complained in the last [time period]".

If a gcc developer notices, or someone finds out while just diddling
around but has no need for gcc on that platform, that wouldn't count.

> And even then, I don't recommend actually *removing* the files, just
> not documenting it as a supported port.  There is great historical value
> in these files and people shouldn't have to find old releases to see them.

I think one reason why many gcc developers have been asking for a more
aggressive deprecation policy is that when there is a change to some
facility that backends use, all the backends must be fixed or (in at
least some cases) they don't even compile.  One possibility would be
to create a subdirectory of gcc/config where the deprecated stuff would
live, and developers would no longer be asked to keep it current.