Re: documenting config.status instantiation order (was: AC_CONFIG_LINKS([sub/file:file]) with abs srcdir creates a bad link)

[Peter Breitenlohner]

On Wed, 6 Jan 2010, Ralf Wildenhues wrote:

Writing this, I had misinterpreted the description of AC_CONFIG_LINKS in
section 4.11 of the manual to say that SOURCE must be in the source
tree. My mistake.

Well, is there text that encourages this interpretation?  If yes then it
should be fixed.

Hi Ralf,

no, the documentation is clear enough.  The misinterpretaion was entirely my
fault.

Do you mean a change like in the patch below?

Not quite. IMHO the addition makes it even less clear. I'd like to say
something like:

@noindent
creates in the current directory @file{host.h} and @file{object.h} as links
to @file{config/$machine.h} and @file{config/$obj_format.h} if such files
exist, or @fi...@var{srcdir}/config/$machine.h} and
@fi...@var{srcdir}/config/$obj_format.h} otherwise.  The file
@file{config/$machine.h} must exist when @var{srcdir} is @samp{.} or could
previously have been created in the build tree, e.g., through
@code{AC_CONFIG_FILES}.

That is quite long-winded, and I don't think it make matters all that
much clearer.  However, your related questions maybe point to a better
way to address the issue:

How about just the first part:

@noindent
creates in the current directory @file{host.h} and @file{object.h} as links
to @file{config/$machine.h} and @file{config/$obj_format.h} if such files
exist, or to @fi...@var{srcdir}/config/$machine.h} and
@fi...@var{srcdir}/config/$obj_format.h} otherwise.

(3) any code afterwards (after `AC_OUTPUT') "is executed by `configure' once
`config.status' was run", but before configuring any subdirectories.

We use this last fact in TeX Live cross compilations to configure a subdirectory
natively, i.e., for the build system.

This part of my previous mail was complete nonsense.  Sorry for the noise.

However, the AC_CONFIG_COMMANDS_POST code is executed after creating
config.status (as documented in 4.10) and after running it (not stated in
4.10), and it is this code we use to switch from cross-configure to native
configure of a subdirectory with auxiliary build tools.

The current semantics are as follows: config.status instantiates any
arguments in the $CONFIG_{FILES,...} variables, defaulting to the
arguments on the command line, defaulting to all listed in configure.ac,

a) first all files, then headers, then links, then commands,
b) sequentially,
c) working on each sub group in the order they were passed on the command
  line.

d) since the subdir/configure invocations are done by configure, they
  happen after config.status has finished (unless --no-recursive).

It is quite conceivable that a future config.status could create several
files or headers in parallel; in fact, that would probably be fairly
straight-forward to implement for well-behaved shells; and for packages
with many config files it would seem desirable.

My view would be to fix and document (a) and (d) but not (b) nor (c),
and we should probably mention that rebuilding rules can recreate files
in arbitrary order (i.e., the rebuilding rules need to take care of
order through dependencies etc).

Is there anything to fix?

I'd like to mention that the AC_CONFIG_COMMANDS_POST code is executed after
stap (a) but before step (d).  And maybe add that any code in configure.ac
after AC_CONFIG_OUTPUT is executed after all that (provided this isn't
already there).

Regards
Peter Breitenlohner <p...@mppmu.mpg.de>