[Top][All Lists]

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

Re: Specifying AM_CPPFLAGS from within

From: Jirka Hanika
Subject: Re: Specifying AM_CPPFLAGS from within
Date: Thu, 2 Jun 2005 22:40:03 +0200
User-agent: Mutt/1.4.1i

On Thu, Jun 02, 2005 at 05:50:14PM +1200, Matthew Walker wrote:
> Hi,
> I would like to know how I should go about specifying AM_CPPFLAGS from 
> within my

For such things, it is VERY useful to add something like this:

include $(top_srcdir)/Makefile.common

at the top of every  This basically gives you a whole new
dimension of performing package administration.  I'm almost surprised
this feature is not built into the automake to dismiss the (small) initial
work investment.  Now write your own Makefile.common and put everything
into it as you please.

Other people use a single  That's not bad, either.  Gives
you much faster builds, at some expense of maintainability.

> I read Norman Gray and Alexandre Duret-Lutz's discussion from this 
> mailing list on this topic 
> ( but could 
> not understand quite what I was supposed to do.

Put this into your


(or rather, AC_SUBST(AM_CFLAGS) as it is something of a conincidence that the
preprocessor and compilation flags tend to have the same effects.)

> The library that I'm working on has an "--enable--full-debug" mode, and 
> I would like to ensure that the compiler spits out all the warnings it 
> can by specifing CPPFLAGS=-Wall.  I have, however, read that setting 
> CPPFLAGS is a bad thing to do because users should be able to alter that 
> variable to their hearts content.

Not every compiler understands -Wall, but newcomers are rarely interested
in hearing that :-)

You are right that CPPFLAGS is not the right tool.

You may wish to stop reading here, and resume reading when you get
automake/autoconf run according to your present wishes :-)
as the rest is less straightforward.

> Any help will be very much appreciated.  I am _very_ much a newbie to 
> autoconf/automake and I apologize sincerely if this is a stupid question.

No it's a fairly standard question.  But you'll probably learn over time that
often it is significantly better to approach these problems from a different
angle.  For example, you don't need to meddle with the autotools at all
in your example - just specify CFLAGS as every other builder would.  It is
simple and automatizable, unless you do development on a different host each
day.  The benefit?  People with different compilers will not have to
fight the non-portable -Wall which happens to break their

Okay, automake gives you the power to distribute (enforce) the options if you
prefer.  But then the portable way to do this is more complex.

Code like the one at the end of the message, when inserted into your
acinclude.m4 (in the top source directory), gives you a MY_CXX_OPTION
autoconf macro to be used like this:

MY_CXX_OPTION(warnings, [warnings], [-Wall -w -enable-warnings-or-whatever])

in, AC_SUBST either "warnings" or AM_CXXFLAGS including these
into the Makefile, and enjoy configure actually selecting the best
warning option from the list for you by examining the actual compiler.
Oh, my example seems to be for C++, so just replace every CXX/cxx by C/c.

If you used CPPFLAGS, the options would affect both C and C++ compilation,
thus there actually IS some difference between CPPFLAGS and CFLAGS.



[AC_MSG_CHECKING([for $2])
[ cat > <<EOF
#include <stdio.h>
int main(int argc, char **argv)
argc=argc; argv=argv; return 0;
for opt in $3; do
    if test -z "${epos_cv_cxx_opt_$1}"; then
        if ${CXX} ${opt} -o conftest 2>conftest2 1>&5; then
            if test -f conftest2; then
                msg=`cat conftest2`
                if test -z "${msg}"; then
if test -z "${epos_cv_cxx_opt_$1}"; then
rm -f conftest conftest2])
if test "${epos_cv_cxx_opt_$1}" = "unknown"; then


reply via email to

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