Re: Warn: non-POSIX variable name

[Peter Johansson]

Steven Woody wrote:
> 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.
>
>
>   

Hi Steven,

If I remember correctly a changed value in "-D flag" will not cause 
re-compilation, so if it is important that the version information 
propagates to your binary, it is likely better to generate a header file 
or even a source file than using these CPPFLAGS. I'm doing that in one 
of my projects in which the makefile.am looks something like this

if HAVE_SVN_WC
@srcdir@/subversion_info.cc: subversion_info.cc.tmp
   @$(SHELL) @top_srcdir@/build_support/move-if-change 
subversion_info.cc.tmp \
   @srcdir@/subversion_info.cc

subversion_info.cc.tmp: FORCE
   @echo '// subversion_info.cc generated from subversion_info.cc.in.' 
> $@ ;\
   revision=`svnversion $(top_srcdir)` ;\
   $(SED) -e 's/sub_2_svn_revision/'$$revision'/g' \
   @srcdir@/subversion_info.cc.in >> $@ ;
endif

FORCE:

Then I have a subversion_info.cc.in that have a string 
sub_2_svn_revision where the revision is intended to be. So when I need 
`subversion_info.cc', a `subversion_info.cc.tmp' is created from the 
`subversion_info.cc.in' using the handy script, svnversion, provided by 
the svn team. Then the script move-if-change replaces 
`subversion_info.cc' with `subversion_info.cc.tmp' (like mv 
subversion_info_cc.tmp subversion_info.cc) but it does so only if the 
two files are different. I introduced that "if" in order to avoid 
re-compilation of subversion_info.o when not needed.

Another thing is that if you plan on distributing your package, you have 
to make sure that it works also when not building from a subversion 
working copy. Either by adding this case in your script `svnrev-sh' or 
by checking it at configure time and add automake conditionals (like I 
do with HAVE_SVN_WC). In any case you probably need to add created 
source code `subversion_info.cc' to your distribution.  I used `make 
distcheck' to help me get the details right.

I am not sure exactly what you wanna do, but I hope this will help.

Good luck
Peter