This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Deprecating or removing protoize, fixproto, -aux-info
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Date: Thu, 22 May 2008 00:37:27 +0000 (UTC)
- Subject: Deprecating or removing protoize, fixproto, -aux-info
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