Following up on an IRC discussion: * The protoize tool has not been built by default for many years, but is still included in the GCC tree (and every so often someone breaks it, because it isn't built by default). Should we remove it from the GCC tree (or deprecate, then remove) and leave it to anyone wishing to use it to maintain a version somewhere else? Someone volunteered a long time ago <http://gcc.gnu.org/ml/gcc-patches/1999-08n/msg00670.html> to create an external version, but I don't think we should wait forever.
* Do we still need fixproto? Again, it breaks from time to time because of patches only tested on non-fixproto systems. Most of the targets set to use fixproto are generic targets such as *-*-elf; on such a target, it's the user's responsibility to produce a suitable set of headers, not GCC's to fix it, and if newlib is being used it's presumably OK without fixproto, because other such targets do not use it. The following non-generic targets use fixproto after my removal of deprecated targets is applied: hppa[12]*-*-hpux10* m32r-*-linux* m32rle-*-linux* mips-sgi-irix[56]* pdp11-*-bsd rs6000-ibm-aix4.[12]* | powerpc-ibm-aix4.[12]* sh*-* (a case with a lot of specific targets) The only ones among those which I think might actually need fixproto are pdp11-*-bsd, mips-sgi-irix[56]* and the old versions of HP-UX and AIX. Could people using those targets comment on the state of the headers with regard to prototypes, what fixproto does on them, how much of that is needed, and whether it could sensibly be moved into fixincludes rules specific to those targets? (I'm inclined to think we could at least say that the use of fixproto is deprecated, remove it from all the targets except those few that might need it, and remove it in 4.5 along with any targets that haven't stopped using it; but maybe it's possible to remove it before then.) * protoize and fixproto are entangled with several other files, makefile rules and features it might be possible to get rid of together, including at least the -aux-info option, sys-protos.h, sys-types.h, scan-types.sh, sort-protos, fix-header, protoize, SYSCALLS.c.X. There was some suggestion on IRC, however, that the -aux-info option might have other uses. Do people think this option is useful to keep if we get rid of protoize and fixproto? There have been discussions of ways of exporting much more structured data from GCC, and GCC variants to do so - but nothing much that so far looks likely to enter official GCC. A complication is that an external protoize might still need -aux-info, unless reimplemented to avoid needing this option. -- Joseph S. Myers [EMAIL PROTECTED]
