On Tue, 22 Dec 2009, Ralf Wildenhues wrote:
Thanks. I've reworked your test case into a couple of testsuite
additions. Below is what I have now. Unless I hear complaints,
I will commit it soonish.
Hi Ralf,
great. I really have to learn that Autotest stuff.
Finally, the manual states that AC_CONFIG_LINKS creates (sym)links from the
source tree to the build tree. ...
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.
.... That sentence might need to be revised.
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}.
Can you think of a more concise wording expressing the same facts?
============================
A somewhat related issue: the description of AC_OUTPUT in section 4.5 states
that "`config.status' performs all the configuration actions" including
subdirectories to configure. There are three points where this description
could be corrected/improved.
(1) It might be useful to state explicitly that config.status (as invoked by
configure) does this in the indicated order: first files, then headers, and
finally links.
(2) config.status does not descend into subdirectories, this is done at the
end of configure.
(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.
============================
Regards
Peter Breitenlohner <p...@mppmu.mpg.de>
