Re: Automake vs. autoheader: config.h.in

[Akim Demaille <akim at epita dot fr>]

>>>>> "Paul" == Paul D Smith <psmith@gnu.org> writes:

Paul> Hi Tom et. al.: I'm working on a trivial doc to include with GNU
Paul> make that gives the exact steps to build it from a clean
Paul> checkout.  I based the algorithm on what autoreconf uses, but I
Paul> can't use autoreconf (mainly due to gettextize issues).

Using a combination of the most recent CVS autoreconf, and the
following bootstrap, I have Bison update properly.  Try it.  I hope
the next gettextize will free us from having a bootstrap file.

| #! /bin/sh
| 
| echo "Bootstrapping CVS Bison..."
| 
| # This will run gettextize which will patch some files, and cause
| # autoconf to choke (because for instance intl/Makefile is registered
| # several times).
| autoreconf --verbose --install --force
| 
| # gettextize modified these files: restore them.
| for f in m4/Makefile.am Makefile.am configure.in
| do
|   if test -f "$f~"; then
|     mv -f "$f~" "$f"
|   fi
| done
| rm -f po/Makevars.template
| 
| # Since some files were restored, some files must probably be remade.
| # But automake could not install all of its files, so pass --install
| # for it.
| autoreconf --verbose --install


Paul> The problem I have is that I have no config.h.in file of my own.
Paul> So, until the last step (autoheader) there is no config.h.in
Paul> file in my directory.  This means that when automake is run as
Paul> the third step, it complains about a missing config.h.in (which
Paul> isn't so bad), and it doesn't add config.h.in to the list of
Paul> common DISTFILES (which _is_ so bad).

Update autoreconf.  It had the logic wrong.