John Klos wrote:

> They all fail in the same place:
> 
> Updating ./version.texi
> restore=: && backupdir=".am$$" &&  am__cwd=`pwd` && cd . &&  rm -rf 
> $backupdir && mkdir $backupdir &&  if 
> (/usr/pkgsrc/devel/gmake/work/.tools/bin/makeinfo --version) >/dev/null 
> 2>&1; then  for f in ./make.info ./make.info-[0-9] 
> ./make.info-[0-9][0-9] ./make.i[0-9] ./make.i[0-9][0-9]; do  if test -f 
> $f; then mv $f $backupdir; restore=mv; else :; fi;  done;  else :; fi 
> &&  cd "$am__cwd"; if /usr/pkgsrc/devel/gmake/work/.tools/bin/makeinfo   
> -I .  -o ./make.info ./make.texi;  then  rc=0;  cd .;  else  rc=$?;  cd 
> . &&  $restore $backupdir/* `echo "././make.info" | sed 's|[^/]*$||'`;  
> fi;  rm -rf $backupdir; exit $rc
> *** Error code 1
> 

I've examined this.  Amazingly, automake-1.9.6 generates Makefiles such 
that info files are regenerated if the configure script is newer than 
the info files.  Why this is, I have no idea.  I see three solutions to 
this:

(1) Touch files in the right order to prevent rebuilding.
(2) Patch the Makefile to avoid regenerating the info files.
(3) Tune the fake makeinfo tool so that it fools the Makefile.

The first two are easy, but we may find ourselves doing it a lot since 
we edit and patch configure scripts quite a lot and I would like to try 
to avoid the effort if possible.  The last one is the interesting 
solution, and I think the semantics we want for the makeinfo script are:

* "makeinfo --version" fails.
* "makeinfo foo.texi" or "makeinfo -o foo.info foo.texi" will look for a
   pre-existing foo.info.  If foo.info exists, then touch foo.info and
   return success, otherwise, fail.

The first rule will make most configure scripts think that makeinfo 
doesn't exist on the system because the majority of them test for 
makeinfo's presence by executing "makeinfo --version".  The second rule 
will cause existing info files to be refreshed to a current timestamp, 
but will fail if asked to generate a new info file.

Are there any objections to implementing this solution?

	Cheers,

	-- Johnny Lam <jlam@pkgsrc.org>