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] |
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