This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: 3.0.4 builds for solaris 2.7 and 2.8
On Feb 24, 2002, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> For example, one way to achieve this would be for the configure
> scripts to accept a new option `--list-supported-options',
Right. The problem is that, from then on, --list-supported-options
becomes a requirement for all sub-configures. Which means you can no
longer use whatever version of autoconf you want (or the sub-package
demands) to generate them, but rather some particular version that
introduces support for this flag.
The best option would be to run `sub/configure --help' and extract the
list of options from that, but even then, you could miss some, because
--help doesn't recurse to sub-sub-packages.
The difficulty lies in the fact that --help is mostly free-hand, and a
number of packages output help with --with-option[=...] and/or
--without-option, ditto for enable/disable, so you'd also have to
filter through that.
Another point to be taken into account is that a package is not
*required* to document all of its options. In fact, packages are free
to use ${enable_option} and ${with_option} variables without any trace
of documentation to that. Starting to prohibit the use of such
options in them would probably not be welcome (as many other changes
introduced in autoconf 2.50 that helped expose bugs in existing
configure.in scripts have shown).
Yet another difficulty is that the top-level configure should pass
down an option to prevent sub-packages from performing the same checks
over and over. This should probably be a regular --disable-* option,
such that packages unaware of yet another option wouldn't error out
when encountering it, so that the top-level configure could pass it
down irregardless of the sub-package supporting it.
Still, I like the idea, and I hope some day we could at least warn
about options not known to be supported. But that's something for
autoconf to take care of, not GCC.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer