Hi Jan. On 11/14/2012 04:44 PM, Jan Engelhardt wrote: > Hi, > > > Is there an option to yield an error instead of a warning > if Makefile.in needs to be regenerated, but can't? > > The case before me is that iptables's Makefile.am in openSUSE is > patched after tarball extraction. But, due to 1. $PEBKAC not calling > autoreconf, 2. the system having automake-1.12 instead, Makefile.in > was not regenerated, which ultimately led to files not being shipped > in the resulting RPM. I would like to catch this case at the auto* > level. > > [ 50s] make[2]: Entering directory > `/home/abuild/rpmbuild/BUILD/iptables-1.4.16.3/iptables' > [ 50s] cd .. && /bin/sh > /home/abuild/rpmbuild/BUILD/iptables-1.4.16.3/build-aux/missing --run > automake-1.11 --gnu iptables/Makefile > [ 50s] /home/abuild/rpmbuild/BUILD/iptables-1.4.16.3/build-aux/missing: > line 52: automake-1.11: command not found > [ 50s] WARNING: `automake-1.11' is missing on your system. You should only > need it if > [ 50s] you modified `Makefile.am', `acinclude.m4' or > `configure.ac'. > [ 50s] You might want to install the `Automake' and `Perl' > packages. > [ 50s] Grab them from any GNU archive site. > [ 50s] cd .. && /bin/sh ./config.status iptables/Makefile depfiles > [ 51s] config.status: creating iptables/Makefile > [ 51s] config.status: executing depfiles commands > [...] > This behaviour is due to the fact that the 'missing' script, when it detects some required developer tools are absent, tries to just update the timestamps of the files that would have been generated by said tools (in this case, automake). This is a remnant from the old CVS days, when the developer-generated files were usually committed; in that case, skewed timestamps from a CVS checkout could cause unnecessary rebuilds, which would fail if the user doing the checkout didn't have all the developer tools -- albeit such tools weren't actually required, as up-to-date versions of the generated files were already present -- just with skewed timestamps.
But luckily, we have already changed this behaviour in the development version of Automake: http://lists.gnu.org/archive/html/automake-patches/2012-06/msg00087.html That change is in the master branch, and will appear in Automake 1.13. That should fix the issue you've reported. HTH, and thanks, Stefano
