Hello Stepan, * Stepan Kasal wrote on Mon, Sep 11, 2006 at 12:26:34PM CEST: > On Fri, Sep 08, 2006 at 09:50:48PM +0200, Ralf Wildenhues wrote: > > > Closer. We need to sleep before the first aclocal, > > I do not understand why, but I'm afraid it has something to do with > your explanation how aclocal and autm4te work. I would be grateful > for an explanation.
Sure. If we don't sleep between the creation of configure.in (sic!) and the invocation of aclocal, then aclocal.m4 may have the same time stamp as configure.in. The second time aclocal is invoked, it will notice that aclocal.m4 is not younger than its inputs, namely it is not younger than configure.in; so aclocal updates aclocal.m4. The updated timestamp will cause the next autoconf to update configure. This behavior is due to how aclocal works: if input and output have the same time stamp, it considers the output outdated, unlike how `make' and `autom4te' behave. (This was the most difficult bug to find, BTW.) The reason I would like the test to call `aclocal' twice (once at the beginning, and once when it should not update anything any more) is to catch further possible bugs: aclocal calls autom4te to trace `AC_DEFUN', `AC_DEFUN_ONCE', `AU_DEFUN', `_AM_AUTOCONF_VERSION', and all macros instantiated in installed configure inputs for which it saw a definition in all the macro files it scanned. The second invocation of aclocal should make sure this set did not change. If it did change, then aclocal.m4 would be updated. > > [...] and sleep before the > > stamp (otherwise it's not guaranteed to be younger than configure), > > Why does stamp has to be younger than configure? Well, I would like the output of `ls -1t configure newer' to not depend upon system-specific issues. If `newer' and `configure' have different time stamps, then there is no problem. If they instead have the same time stamp, the sort order depends upon the locale. It's not easy to imagine a locale where `newer' sorts before `configure', but it's easy to avoid having to think about issues like this: by making sure they always have different time stamps. With this in mind, I have to differentiate between - the `configure' that is generated by the first `autoconf' invocation (which, in case autom4te.cfg is good, is also the only generated one), - and the `configure' that may be generated by the second `autoconf' invocation (in case autom4te.cfg specified too few macros, or the test should fail for some other reason). I would like both failure and success to be deterministic. Thus sleeping before and after stamp file creation. > Actually, I would use `test -r configure stamp' if it were portable. I don't understand what you would like to achieve with this. > > * configure.ac: Preserve original values of `$AUTORECONF' > > and `$AUTOHEADER', to avoid the `missing' script. > > * tests/defs.in: Adjust. > > You deleted am_AUTORECONF from the code, but not from the chlog > entry. Thanks for noting this; I'll fix the ChangeLog entry. > I suggest to reinstert it to the code, to prevent an > unpleasant surprise later. Well, it is not needed in the testsuite at the moment, and it seems not likely that it will be needed; and even if it would, bypassing `missing' is merely an optimization, is does not harm execution. To paraphrase in your own words: Why have code that is never used? Cheers, Ralf
