top-level configure options, --help

top-level configure options, --help

[NightStrike]

I noticed that --with-sysroot is not listed in --help for the top
level configure, but --with-build-sysroot is.  Is that on purpose?
Should the former not be used at all in place of the latter?

Re: top-level configure options, --help

[Ian Lance Taylor]

NightStrike <nightstrike@gmail.com> writes:

> I noticed that --with-sysroot is not listed in --help for the top
> level configure, but --with-build-sysroot is.  Is that on purpose?
> Should the former not be used at all in place of the latter?

This is an unfortunate artifact of autoconf --help handling with
recursive configure scripts.  You'll see both mentioned in the output
of gcc/configure --help.  --with-build-sysroot needs to be handled at
the top level in order to pass down the --sysroot option when
compiling libraries; therefore, it appears in the top level --help
output.  --with-sysroot does not need to be handled at the top level;
therefore, it does not appear in the top level --help output.

Ian

Re: top-level configure options, --help

[NightStrike]

On 02 Jan 2008 08:54:39 -0800, Ian Lance Taylor <iant@google.com> wrote:
> NightStrike <nightstrike@gmail.com> writes:
>
> > I noticed that --with-sysroot is not listed in --help for the top
> > level configure, but --with-build-sysroot is.  Is that on purpose?
> > Should the former not be used at all in place of the latter?
>
> This is an unfortunate artifact of autoconf --help handling with
> recursive configure scripts.  You'll see both mentioned in the output
> of gcc/configure --help.  --with-build-sysroot needs to be handled at
> the top level in order to pass down the --sysroot option when
> compiling libraries; therefore, it appears in the top level --help
> output.  --with-sysroot does not need to be handled at the top level;
> therefore, it does not appear in the top level --help output.

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.

Re: top-level configure options, --help

[Brian Dessent]

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

Re: top-level configure options, --help

[NightStrike]

On 1/6/08, Brian Dessent <brian@dessent.net> wrote:
> 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.

Ah, thank you for this.  Where is this recursive help documented?

Re: top-level configure options, --help

[Brian Dessent]

NightStrike wrote:

> Ah, thank you for this.  Where is this recursive help documented?

It's mentioned in the normal --help boilerplate of any standard
autoconf-generated configure:

  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included
packages

Brian