public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Brian Dessent <brian@dessent.net>
To: NightStrike <nightstrike@gmail.com>
Cc: Ian Lance Taylor <iant@google.com>,  	gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: top-level configure options, --help
Date: Mon, 07 Jan 2008 14:14:00 -0000	[thread overview]
Message-ID: <4780B42E.7D863082@dessent.net> (raw)
In-Reply-To: <b609cb3b0801021330n7de05e4dm441b038192d4b5e6@mail.gmail.com>

NightStrike wrote:

> If that's the case, there must be more options as well that are not
> present in top level's --help that really are options that the user
> would actually use.  I would think that a simple AS_HELP_STRING macro
> in the top level configure would accomplish this.  That, or a blank
> ARG_WITH macro.. something like:
> 
> AC_ARG_WITH([sysroot],
>   [AS_HELP_STRING([--with-sysroot],
>     [Sets the sysroot])],
>   [],
>   [])
> 
> You could list the option in the top level configure, but give it no
> action.  This is a benefit to the user, so that the top level
> configure --help contains all the options that a user would use.

That's no good.  You're just duplicating stuff already in
gcc/configure.ac, which means now you have two copies in two separate
directories of every option to maintain, which is a real pain, and it is
a recipe for things getting out of sync.  I doubt any maintainer would
accept this.

Besides, the toplevel configure machinery is shared between a number of
projects, so it really shouldn't have specific knowledge of options
implemented in particular subdirs that may or may not be present in the
tree.  The sysroot example is perhaps not the best one because it is
probably implemented by all the tools that share this file, but it is
certainly not true in general.  You'd end up shipping a e.g. gdb tarball
that advertises meaningless configure options in its --help that don't
do anything because they only apply to gcc/ or libstdc++/ or
libgfortran/ or whatever dirs that aren't present in the gdb subset of
the tree.

The real solution is supposed to be --help=recursive which in a normal
autoconf project runs the --help in the top dir and then the --help of
each existing subdir's configure.  But for whatever reason, this has
never worked with the src/gcc toplevel configure, which is a shame
because the number of options that are specific to various subdirs (i.e.
not listed by the toplevel configure) is quite large.  But it's simple
enough just to tell users to run e.g. gcc/configure --help or
libstdc++-v3/configure --help or whatever until somebody fixes
--help=recursive.

Brian

  reply	other threads:[~2008-01-06 10:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-29 20:47 NightStrike
2008-01-04  2:18 ` Ian Lance Taylor
2008-01-04  6:13   ` NightStrike
2008-01-07 14:14     ` Brian Dessent [this message]
2008-01-07 14:25       ` NightStrike
2008-01-07 22:27         ` Brian Dessent

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=4780B42E.7D863082@dessent.net \
    --to=brian@dessent.net \
    --cc=gcc-help@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=nightstrike@gmail.com \
    /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).