Re: Do fail when regeneration of Makefile.in does not succeed

[Stefano Lattarini]

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