Re: cvs and autoconf

[Greg A. Woods]

[ On Saturday, May 12, 2001 at 18:18:22 (-0700), Byron Young wrote: ]
> Subject: cvs and autoconf
>
> A tutorial from the distribution autotools-0.11.tar.gz has a hello
> application example (specifically, in section Using Configuration
> Headers). For those of you familiar with the GNU autoconf tools, which
> files would you commit to cvs for revision control? And what would be
> the best way to accomplish the task, so that, in the future, as the
> project complexity increases, further additions to the repository would
> be as painless as possible?

Never ever commit anything that's generated by any tool.  Only commit
source.

If you get only slightly lazy in this respect and commit even one very
rarely regenerated file you'll make your build process much harder to
understand and much easier to break.  If you stick to your guns and make
sure that your build process always manages the construction of every
generated file then you can be far more certain that every build is
correct and reproducible (at least with the same tools: -).

If you use GNU Automake then you'll automatically get Makefiles that are
capable of re-generating everything.

I.e. with makefiles generated automake run "make maintainer-clean"
first before figuring out if you've any new files to "cvs add" or if
you're importing some third-party code then do:

        ./configure --enable-maintainer-mode
        make maintainer-clean

(Of course none of this means that you can't ship some generated files
in your source distribtuions -- it just means that no developer should
ever be so lazy as to avoid installing and using *all* of the tools
necessary to regenerate every generated file.  Note that even people
working on third-party code are properly called "developers" in this
case and they must strive to create a build environment that's capable
of regenerating all generated files when they're building the code.
It's not like it's hard, time consuming, or any real bother at all to
install at least all the GNU Auto* tools, GNU Make, etc.)

BTW, I personally wouldn't recommend using Autoconf without Automake.

> Also, is there a way to correlate cvs tags with the autotools version
> number?

Ah ha!  That's a very good question!

There's no real solution within CVS.  If you do things that way then
it's simply a matter of choosing some naming convention.

You can also use some manually maintained "manifest" file that's
committed, tagged, and released, as part of the entire source tree to
record which tools are used at every milestone.

You may even be able to automate the construction of your tools manifest
by creating it during the build process (and herein lies an example of
the "exception" to every rule:  if you automatically generate this
manifest file during your build then it's the one generated file that
you must commit!  ;-).  The *bsd packaging system does something like
this to some extent when it creates the build-info file that's included
in each binary package (and in the installed package database).

Either way you have to ensure that you can either install multiple
versions of all of your tools on your build machine(s) or that you can
re-create your build tool environment on demand.

Of course it's also very important to note that Autoconf and Automake
are tools designed to eliminate dependencies on many other tools and
attributes of the build and target systems.  Autoconf is probably the
only tool that you really have to be careful with, but if you take care
it's possible to write configure.in scripts that'll work well enough
with many different releases of Autoconf itself.  In other words it's
often possible to effectively ignore tool dependencies and therefore not
to have to worry too much about recording which tool versions are needed
to build some given release of your code.  The more complex your code
and the target environment, and the more specialised your build tools,
the less this generality will apply, of course.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>