Steven Woody wrote: > Thank you. Adding -Wno-portablility to AM_INIT_AUTOMAKE works. But I > don't understand your other words: "For the former, > run the script at configure-time rather than at make-time and AC_SUBST > the resulting value."
I mean adding something like the following to configure.ac: SVN_REV=`$top_srcdir/svnrev-sh` SVN_DATE=`$top_srcdir/svndate-sh` AC_SUBST([SVN_REV]) AC_SUBST([SVN_DATE]) And then in your Makefile.am: rmeterd_CXXFLAGS = -DSVN_REV='@SVN_REV@' -DSVN_DATE='@SVN_DATE@' (That should most likely be CPPFLAGS not CXXFLAGS but that wasn't the question.) The difference with this method is that the values are computed once when configure is run, and then substituted into the Makefile when it is generated after configure has completed. When you use $(shell ...) the value is not computed until you run make, and the result is not stored anywhere so it is recomputed each time that make is run. The main advantage of doing it this way is that it's portable to systems without GNU make, since $(shell) is a feature of GNU make -- that is what the automake warning is telling you. A second advantage is that since the values are substituted into the generated Makefile, there is no delay waiting for the scripts to execute each time you run make. Whether this matters depends on how expensive the operations are, but with very large trees some version control operations can take a lot of time so it's generally a good idea to not have to run them over and over again. On the other hand this also means that the stored version information will not reflect the outcome of e.g. "svn up" as it will only change after the package is reconfigured. However if most of your configure tests are properly designed to support caching (and you enable caching, e.g. configure -C) then "./config.status --recheck" ought to be a fairly fast operation that you can run after performing a version control operation in order to get the new revision information in the generated Makefile. Brian
