[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "configure --help=recursive" only works in top_srcdir
From: |
Hans Ulrich Niedermann |
Subject: |
Re: "configure --help=recursive" only works in top_srcdir |
Date: |
Sun, 01 Jul 2007 17:18:18 +0200 |
User-agent: |
Thunderbird 1.5.0.12 (X11/20070530) |
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