Deprecating or removing protoize, fixproto, -aux-info

Deprecating or removing protoize, fixproto, -aux-info

[Joseph S. Myers]

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
joseph@codesourcery.com