Re: Warn: non-POSIX variable name

[Steven Woody]

On Tue, Aug 19, 2008 at 3:43 PM, Brian Dessent <address@hidden> 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.