This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Retiring obsolete files


One of the problems with maintaining GDB over a long period of time is
that, unlike GCC, GDB includes files that can only be compiled and run
on a particular host.  If the host is obsolete or simply scarce, it
becomes impossible to ensure that GDB's code for that host is still
correct, and in fact that code may actively mislead current and future
maintainers looking for examples of how to solve a problem.

I discussed this with RMS, and he wasn't keen to simply delete files,
for the reason that one doesn't necessarily know for sure that the
configuration no longer exists, and if someone wanted to revive it, it
might be very difficult to find a GDB release with the old files still
present.  However, he thought it would be OK to mark files as
obsolete.  So I came up with a compromise proposal that I'd like to
try out on people.

Files that seem to be obsolete first get marked with this sed script:

	sed -e 's,*/,*//*,g' -e 's,^,/* OBSOLETE ,' -e 's,$, */,'

This puts the word 'OBSOLETE' on every line, plus comments out all the
code, thus making its status obvious to readers, to grep, and to any
source analysis tools that might look inside a #if 0 ... #endif.  In
addition, the gdb/NEWS file gets a note to the effect that a file or
config is obsolete.  This situation lasts for one release.  Then, at
the time of the next release, if no one has come forward to save the
file, it gets deleted, and a note is made of that in NEWS.  Over time,
old junk will disappear from the source, thus making room for new junk. :-)

Opinions?  If no one objects, I will set this in motion for 4.18.

								Stan