This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Remaining host configuration fragments
- From: Joe Buck <jbuck at synopsys dot COM>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: dj at redhat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 17 Jan 2002 11:53:40 -0800 (PST)
- Subject: Re: Remaining host configuration fragments
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.