Re: "configure --help=recursive" only works in top_srcdir

[Hans Ulrich Niedermann]

Ralf Wildenhues wrote:

> * Hans Ulrich Niedermann wrote on Mon, Jun 25, 2007 at 06:20:53PM CEST:
>>    "configure --help=recursive" does not run the --help parts of the
>>    directories included via AC_CONFIG_SUBDIR when called as
>>        $ /path/to/top_srcdir/configure --help=recursive
>>    or
>>        $ ../configure --help=recursive

> Actually, this is an ugly bug.  It goes away if you do
>   mkdir direct-sub
> in the current working directory.  Consequently it is not visible once
> you are in a configured build tree.

That is nice, but the purpose of --help and --help=recursive is to find
out what configure options one wants to use to configure the build tree.
So we have chicken-egg problem here.

General note from my side: I had no idea this bug would turn out to be
that ugly :-/

> The reason configure does not enter the source tree is that the source
> tree may live on read-only media, and the sub-configure needs to be able
> to write to the CWD before it gets to help output (for example to find
> out $PATH_SEPARATOR).  OTOH having
>   configure --help=recursive
> 
> create the build subtree (1) (and document that) seems like an ugly
> solution, too.

I agree. The user expectation is that running a program with "--help" or
"--version" just prints the help text or version and then exits without
causing *any* side effects.

> The next best thing I could come up with would be to use the same build
> directory for each of the sub configure scripts (2).  But there is a
> failure scenario for that:  Say, the shell does not support $LINENO
> properly.  In that case, we create and execute "configure.lineno" in the
> current directory.  The sub configure script will try to overwrite the
> same script.  As the toplevel script is still in use by the parent
> shell, it won't be overwritable on, say, some NFS volume.

OK, scratch that, then.

> My next idea was: --help=recursive creates a build tree if necessary
> (3).  It remembers whether it had to create the tree, and if so, tries
> to clean up after itself.  Implementation-wise, however, this is a mess
> (What if, with AC_CONFIG_SUBDIRS([deep/sub/dir]), deep/sub exists but
> not deep/sub/dir, should we remember to only remove the last
> component?).

Eek. That remembering stuff in /bin/sh would be ugly.

> Lastly (4), we could just document the current situation.  The prospects
> of having to run configure just to find out about all of its options are
> bleak, though.

That documentation would entail some output like

   $ ../configure --help=recursive
   [...]
   NOTE: Run configure without --help to get help for these directories:
       direct-sub
       deep/sub/dir
   $

> I'd vote for (1).  The proposed patch below implements that.  What's the
> general opinion about this?

I'd advise against (1) as it introduces (even more) side effects into an
operation which is expected to be free of them.

Suppose I have just extracted a source tree somewhere and now I run

  address@hidden ~]$ ./src/package-1.2.3/configure --help=recursive

to find out what options are available. I definitely would not want or
expect configure to create directories or files in my $HOME now!

I'd prefer documenting the problem and printing a helpful error message
if the problem is encountered over (1).

That leads me to a few more ideas for a fix, based on your elaborations:

(1a) If configure cannot confirm that $CWD is a configured build tree,
ask the user for confirmation before "--help=recursive" starts to create
subdirectories.

(5) Find some temporary directory we have write access to and create the
subdirectories there (e.g. "mktemp -t -d" if available).

(6) Get rid of the write requirements. Does "--help=recursive" really
require PATH_SEPARATOR and the other things determined via writing to disk?

signature.asc
Description: OpenPGP digital signature