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 @address@hidden/config/$machine.h} and
> > @address@hidden/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 @address@hidden/config/$machine.h} and
@address@hidden/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 <address@hidden>