Re: Unnecessary running of configure with fatal consequences

[Ralf Wildenhues]

* Joost Kraaijeveld wrote on Wed, Dec 03, 2008 at 11:28:56PM CET:
> On Wed, 2008-12-03 at 21:57 +0100, Ralf Wildenhues wrote:
> 
> > That's the first issue.  Most likely due to messed up time stamps,
> > maybe due to the packing/unpacking process?  w32 file systems may have
> > different time stamp granularity or so.  But with a correctly packaged
> > tarball, I don't think this should happen.
> 
> Mmmmm. No tarball, just a checkout of an SVN repository. The Linux
> checkout of exactly the same source does not exhibit this behaviour, but
> I will look into it more closely than I have done so far.

I forgot one data point here: one thing that may happen is that, with
existing, higher-precision time stamps to be mapped onto file systems
with lower ones, one tool may round backwards and one forwards.  I don't
know if there are file system-inherent differences, too, here, but would
not be surprised.

> > - there are third-party macros needed for regenerating files which are
> > either not packaged with your package, or not found by aclocal.  The
> > solution to the former is typically, to install them in m4/ (which can
> > be done with new 'aclocal --install' if AC_CONFIG_MACRO_DIR([m4]) is
> > used in configure.ac), the solution to the latter is to add
> >   ACLOCAL_AMFLAGS = -I m4
> > to the toplevel Makefile.am file.
> I am under the impression that these 3th party macros (which are
> definitely in the original aclocal.m4 file!) do not have to distributed,
> as they are included in the aclocal.m4 which renders the configure file
> selfcontaining in terms of the macros , am I wrong about that?

You are right in that third-party macro files do not have to be
distributed.  If they are not, then when aclocal is run, it copies them
into aclocal.m4.  However, it can only do so if it finds them in, say,
/usr/share/aclocal.  Which probably works on one system, and fails on
another.

Distributing these third-party macro files would have the benefit of not
requiring these installed files.  Note that, with modern aclocal, they
don't increase the size of your tarball: when a macro file m4/foo.m4 is
used, then aclocal won't copy its contents into aclocal.m4, but instead
merely add a line containing 'm4_include([m4/foo.m4])'.

> > Well, whether any or all of the files are regenerated, depends on
> > the relative time stamps.  If the restoration process leaves
> > aclocal.m4 new enough, then it will likely not be regenerated next
> > time.  I assume it's this part that is buggy for you.
> This would suggest that a simple "touch aclocal.m4" after a check out
> would solve the problem or am I missing something (I rather ask, because
> compilation of the complete tree takes ~4 hours on my VirtualBox Windows
> XP...) ?

Well.  I wasn't complete in listing work-arounds and fixes, either.
One fix for one of the issues was already mentioned: distribute the
third-party files used.

Now to the time stamp issue:  one way to work around it is to use
AM_MAINTAINER_MODE, see 'info Automake maintainer-mode' for details.

* Joost Kraaijeveld wrote on Wed, Dec 03, 2008 at 11:31:28PM CET:
> 
> On which of all the generated file timestamp does the configure script
> depends?

Well.  configure typically depends on acinclude.m4, aclocal.m4,
configure.ac, and all files m4_include'd by these, recursively.
aclocal.m4 itself typically depends on all its m4_include'd files.
The Makefile.in files typically depend on all files configure
depends upon, plus the respective Makefile.am file.

With GNU make, one way you should be able to update time stamps without
updating any files is something like
  make -t aclocal.m4 configure Makefile

but I would like to advise you to use this (like any other time stamp
munging) with caution, as a wrong move can lead you to an inconsistent
tree.

Cheers,
Ralf