Richard Megginson wrote:
> Andrew Bartlett wrote:
>> On Wed, 2006-10-25 at 18:14 -0700, Pete Rowley wrote:
>>
>>> Andrew Bartlett wrote:
>>>
>>>> Our current policy is to generate these files for release tarballs,
>>>> and
>>>> for our 'unpacked' tree on
samba.org (current SVN checked out).
>>>>
>>> OTOH they are required in order to do:
>>>
>>> cvs co
>>> ./configure
>>> make
>>>
>>
>> Yeah, projects typically end up with an ./autogen.sh to make the right
>> innovation of the configure generation tool.
>>
> I've found that using autoreconf usually does the right thing. When I
> change configure.ac/in or Makefile.am or an .m4 file, I always run
> autoreconf -vfi
> -v, --verbose verbosely report processing
> -f, --force consider all files obsolete
> -i, --install copy missing auxiliary files
> It takes a little longer, but I almost never have conflict or
> timestamp problems. Plus, it's part of the standard autotools
> package, and it is the way the autoconf/automake manuals recommend
> rebuilding the autotool files.
> For some projects, this won't work (e.g. for mozldap, you have to just
> use autoconf-2.13, not autoreconf or autoreconf-2.13).
As I just very recently found out, we also need a very specific version
of libtool (1.5.22) to generate ltmain.sh if we want to be able to build
a 64-bit Directory Server on Solaris. Running "autoreconf -fvi" will
generate a new ltmain.sh that may be a version that we don't want to
check in if we expect to be able to immediately run "configure; make
install" after checking out the code.
-NGK
The real pain is when not all of the files have changed and you check in
only those that did. This can cause an unwanted auto* rebuild.
I've taken to checking everything in at once whenever one thing changes
with:
cvs ci -f Makefile.am configure.in aclocal.m4 Makefile.in configure
This preserves the proper timestamp/dependency order (at least for me).
rob