* 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