On Mon, 2005-12-19 at 20:11 +0000, Harlan Stenn wrote: > > On Mon, 2005-12-19 at 00:15 +0000, Harlan Stenn wrote: > > > The problem with doing these things in configure is that one must rerun > > > configure to regenerate the file. > > > > > > Sometimes it is better do produce these things in config.status. > > > > There is no need to do so, in this case, because the file is being > > generated when running configure. > > For certain definitions of "need", I agree with you. > > > "config.status --recheck", runs configure, so changes to configure.ac > > automatically get propagated to the generated file. > > For packages that are "big enough" (ie, that have a large/slow run of > "configure"), this is an unnacceptable solution. 1. This approach generates some sort of autoheader (Actually an exported, generated (auto-) header). The only situation such headers _can_ change is "changes to configure.ac" or "config.status --recheck". A plain "./config.status ...." would only be required, if a user removes/trashes the generated file (cf. ./config.status <file>). 2. The package, I apply this approach to, isn't necessarily "big" code size-wise, but it is "complex and big", autotool-wise ;-) (http://www.rtems.org/cgi-bin/viewcvs.cgi/rtems/cpukit/configure.ac) Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
