automake
[Top][All Lists]
Advanced

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

Re: Warn: non-POSIX variable name


From: Brian Dessent
Subject: Re: Warn: non-POSIX variable name
Date: Tue, 19 Aug 2008 00:43:50 -0700

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




reply via email to

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