public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@redhat.com>
To: Fergus Henderson <fjh@cs.mu.OZ.AU>
Cc: lucier@math.purdue.edu, gcc@gcc.gnu.org
Subject: Re: 3.0.4 builds for solaris 2.7 and 2.8
Date: Sun, 24 Feb 2002 04:14:00 -0000	[thread overview]
Message-ID: <or1yfbdqvb.fsf@free.redhat.lsd.ic.unicamp.br> (raw)
In-Reply-To: Fergus Henderson's message of "Sun, 24 Feb 2002 21:15:39 +1100"

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

  reply	other threads:[~2002-02-24 12:08 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-22 20:05 lucier
2002-02-22 20:31 ` Alexandre Oliva
2002-02-22 20:43   ` Brad Lucier
2002-02-22 20:47     ` Alexandre Oliva
2002-02-22 21:01       ` Brad Lucier
2002-02-22 21:49         ` Alexandre Oliva
2002-02-24  2:26   ` Fergus Henderson
2002-02-24  4:14     ` Alexandre Oliva [this message]
2002-02-24  6:21       ` Fergus Henderson
2002-02-24 19:23       ` Phil Edwards
2002-02-24 11:42   ` Mark Mitchell
2002-02-24 13:28     ` Alexandre Oliva
2002-02-25  7:39   ` Peter Barada
2002-02-25  8:54     ` Alexandre Oliva
  -- strict thread matches above, loose matches on Subject: below --
2002-02-22 15:42 George.R.Goffe
2002-02-22 16:28 ` Alexandre Oliva
2002-02-22 17:26 ` Janis Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=or1yfbdqvb.fsf@free.redhat.lsd.ic.unicamp.br \
    --to=aoliva@redhat.com \
    --cc=fjh@cs.mu.OZ.AU \
    --cc=gcc@gcc.gnu.org \
    --cc=lucier@math.purdue.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).