On Tue, Aug 19, 2008 at 3:43 PM, Brian Dessent <[EMAIL PROTECTED]> wrote: > 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.
Thanks for the explaination, it improves my knowledge in automake. But, for the case, I wish the version information as updated as possible since team member may forget to run "./config.status --recheck", this will leave generated programs with a wrong version info. Thank you anyway.