[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Warn: non-POSIX variable name

From: Peter Johansson
Subject: Re: Warn: non-POSIX variable name
Date: Tue, 19 Aug 2008 09:44:30 -0400
User-agent: Thunderbird (X11/20080723)

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


And then in your


(That should most likely be CPPFLAGS not CXXFLAGS but that wasn't the

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

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 looks something like this

@$(SHELL) @top_srcdir@/build_support/move-if-change \
   @srcdir@/ FORCE
@echo '// generated from' > $@ ;\
   revision=`svnversion $(top_srcdir)` ;\
   $(SED) -e 's/sub_2_svn_revision/'$$revision'/g' \
   @srcdir@/ >> $@ ;


Then I have a that have a string sub_2_svn_revision where the revision is intended to be. So when I need `', a `' is created from the `' using the handy script, svnversion, provided by the svn team. Then the script move-if-change replaces `' with `' (like mv subversion_info_cc.tmp 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 `' 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]