Its usually good form to not track the configure
script at all. There are some reasons for this:
Its huge. I've seen code bases where the configure script and helper macro libraries were more than ten times the size of the actual code being compiled.
When other developers make changes to configure.in(.ac), they are going to need to commit a new configure
script. If three people do that, there's a good chance that Mercurial will require at least one of them to manually resolve a merge conflict in configure
itself. Keep in mind, configure
is machine generated, attempting to read it (much less resolve merge conflicts) may make your eyes bleed.
Generally, you'll offer a program in source form via two methods:
Download of a release archive (e.g. foo-1.2.3-rc2.zip), this can contain the configure script.
Downloading the repository directly using Mercurial. If they want to work with that, they'll need to have autoconf installed.
In the root of my repositories, I usually include a file called autogen.sh
that runs all of the steps needed (aclocal
, autoconf
, ...), which also handles alerting the user if they need something installed. I.e. Could not find tool aclocal, please install the autoconf package.
Its really best to just go with the autogen.sh
method. This means only tracking configure.in (or configure.ac) and the associated Makefiles (from Makefile.in). Let each build configure their own, and provide a distclean
target to remove all files configure
generates. Finally, provide a maintainer-clean
target to remove anything that the configuration suite itself generated, e.g. configure
.
That should help make nightly builds easy.