This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Remaining host configuration fragments
- From: Stan Shebs <shebs at apple dot com>
- To: Joe Buck <jbuck at synopsys dot COM>
- Cc: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, dj at redhat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 17 Jan 2002 14:09:19 -0800
- Subject: Re: Remaining host configuration fragments
- References: <200201171953.LAA27441@atrus.synopsys.com>
Joe Buck wrote:
>
> > 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.
When I went around on this with RMS for GDB, he agreed that it was
reasonable to "mark files as obsolete". So I did a little script
that added the strings "/* OBSOLETE " and "*/" to the beginning
and end of every line of the file (and escaped comments within
lines, duh). This both gets the point across to current developers
(and to any automated tools that browse source files), and leaves
everything exactly in place, so that the future would-be reviver
can recover the config from the last release before final deletion,
simply by reverting the edits.
GDB has been doing this for a couple years now, and so far the
trip to obsolescence has always been one-way.
Stan