[Cvs-dev] Re: [Cvs-cvs] ccvs/windows-NT ChangeLog config.h.in config.h

[Derek R. Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim Hyslop wrote:
> Derek R. Price wrote:
>>> Please don't change the config.h.in files.  They are *both*
>>> autogenerated.  The top level one is generated by autoconf from the
>>> configure.in file.
> 
> Right. Methinks I need to learn more about using autoconf. Any pointers
> to quick-start guides?

The system is rather complex and I don't know if there is a quick start
guide.  `info autoconf' after installing autoconf (and GNU info) should
get the Autoconf manual.  It is also online
<http://www.gnu.org/software/autoconf/manual/autoconf.html>.


In short (you may want to skip to the "To boil this down even more" at
the end):

GNULIB may add macro files to the m4/* directory and we have a few in
there ourselves.

Automake's `aclocal' file builds up an `aclocal.m4' file from various
macros provided by Automake, plus the files installed in m4/.

Autoconf's `autoheader' turns the macros and shell script in
`configure.in' and `aclocal.m4' (remember, including Automake's macros
and m4/*) into config.h.in.

Autoconf's `autoconf' turns `configure.in' into `configure'.

Automake's `automake' then reuses `configure.in' and `aclocal.m4'
(remember, including Automake's macros and m4/*) to turn all the
`Makefile.am' files into `Makefile.in' files.


All these commands should only need be run by maintainers (us), leaving
users on to:

`configure && make' (`configure' turns all `Makefile.in's into
`Makefile's, as well as generating a few other files, as described in
the macros in `configure.in', m4/*, & Automake).


There are ASCII diagrams of much of this in the Automake and Autoconf
manuals if you want a visual.  To boil this down even more:

1.  The only top level build files you should ever edit are
configure.in, any Makefile.am, and m4/* files (for Windows, of course,
there is config.h.in.in, config.h.in.footer, and the MSVC project files,
but I covered those in an earlier email).

2.  If you edit an m4/* file which came from GNULIB (most of them), then
we generally need to push the change upstream to GNULIB (this also goes
for lib/* files from GNULIB, again, most of them).

3.  If you edit any Auto{conf,make} source file(s), then you can attempt
to forget about the whole complex inter-relationships and run Autoconf's
`autoreconf' to regenerate any files that need regenerating.  This
usually works and always works if you `touch configure.in && autoreconf'
(`cvs update' can sometimes munge timestamps inappropriately).
`autoreconf -m' will also reconfigure and `make' when done rebuilding
the Auto* generated build files.

4.  If you `configure --enable-maintainer-mode' (and have Autoconf,
Automake, Perl, and any dependencies installed), then a simple `make'
will also rebuild the Auto* generated build files, assuming things
haven't gotten too out of whack.  When things are so out of whack that
`touch configure.in && make' doesnt't rebuild the Auto* generated files
with maintainer mode enabled, `touch configure.in && autoreconf -m' will
do the trick, assuming that the problem isn't a syntax error or the like
in one of the Auto* source files.

5.  You should never need to `autoreconf' Auto* source files.  You
should never need to enable maintainer mode if you do not either alter
one of the Auto* build files or alter `window-NT/config.h.in.{in,footer}'.


Clear as mud?

Cheers,

Derek
- --
Derek R. Price
CVS Solutions Architect
Get CVS support at Ximbiot <http://ximbiot.com>!
v: +1 248.835.1260
f: +1 248.835.1263
<mailto:address@hidden>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEroBoLD1OTBfyMaQRAlz/AKCxg15NSCfQD1UE2uuMtoiQ6RNnPwCdGV8a
WiduXr647xgkw7uHdDuH7nA=
=ECjk
-----END PGP SIGNATURE-----