On Thursday 11 November 2010, Joost Kraaijeveld wrote:
> Hi,
Hello Joost.
Sorry if I start my answer with criticism, but this subject ...
"Two questions: warning: macro `AM_CPPFLAGS' not found in library
and how to assign values?"
... already tells me that you should have presented your questions
in two distinct mails. Oh well, for the next time :-)
Now to the real stuff ...
> I am getting this warning
The warning is triggered because, to aclocal, AM_CPPFLAGS "looks like"
an automake macro (as `AM_CONDITIONAL' or `AM_INIT_AUTOMAKE' are), and
since it is not able to find a definition for it, it guesses that a
problem has occurred somewhere, and warns about.
Anyway, aclocal is smart enough to recognize that a line like, say,
`AM_CPPFLAGS=foo', is just a variable assignment, and thus that
AM_CPPFLAGS should not be considered as an automake macro in such
a case.
So this warning should disappear once you've fixed your configure.ac
(which in fact contains several errors, see below).
> (and if I configure an error, "AM_CPPFLAGS: command not found")
That's because you used `$(AM_CPPFLAGS)' in your configure.ac below
as if it were a variable substitution, but it's not; it's a command
subsitution, and causes the shell to try to run `AM_CPPFLAGS' as
a command, and substitute the output of such a command in place of
`$(AM_CPPFLAGS)'; since no such command is present, the shell
errors out.
> for the piece of configure.ac below.
> What is the correct way to achieve what I want: an incremental
> build up of AM_CPPFLAGS?
That's a good question. You can either extend AM_CPPFLAGS at configure
time, and AC_SUBST it, as in the following example:
$ cat configure.ac
...
AM_CPPFLAGS=-DBAR=1
if test "$use_gcc_warnings" = yes; then
AM_CPPFLAGS="$AM_CPPFLAGS -Wall"
fi
if test "$debug" = no; then
AM_CPPFLAGS="$AM_CPPFLAGS -DNDEBUG"
fi
FOO_VALUE=`a-complex-command-computing-the-vaue-of-foo`
AM_CPPFLAGS="$AM_CPPFLAGS -DFOO='$FOO_VALUE'"
AC_SUBST([AM_CPPFLAGS])
...
or define the various AM_CPPFLAGS components at configure time as
proper variables, AC_SUBST them, and then put them togheter in a
AM_CPPFLAG definition in Makefile.am, as in the following example:
$ cat configure.ac
...
if test "$use_gcc_warnings" = yes; then
CPP_WARN_FLAGS=-Wall
else
CPP_WARN_FLAGS=
fi
AC_SUBST([CPP_WARN_FLAGS])
if test "$debug" = no; then
CPP_DEBUG_FLAGS=-DNDEBUG
else
CPP_DEBUG_FLAGS=
fi
AC_SUBST([CPP_DEBUG_FLAGS])
FOO_VALUE=`a-complex-command-computing-the-vaue-of-foo`
AC_SUBST([FOO_VALUE])
...
$ cat Makefile.am
...
AM_CPPFLAGS = -DBAR=1 $(CPP_WARN_FLAGS) $(CPP_DEBUG_FLAGS) \
-DFOO='$(FOO_VALUE)'
...
I personally prefer the idiom used in the second example.
> And a second question:
(Just another small nit: such a question is not automake-specific,
and would be better asked on, say, the comp.unix.shell newsgroup,
or something similar).
> should all these assignments work
>
> 1. PLATFORM_CPPFLAGS = -DLINUX_DLL // spaces
> 2. PLATFORM_CPPFLAGS=-DLINUX_DLL // no spaces
> 3. PLATFORM_CPPFLAGS = "-DLINUX_DLL" // spaces and ""
> 4. PLATFORM_CPPFLAGS="-DLINUX_DLL" // no spaces and ""
I assume these assignements are supposed to be in a shell script, right?
Then you must *not* use extra spaces around `='.
Thus:
PLATFORM_CPPFLAGS = -DLINUX_DLL
PLATFORM_CPPFLAGS = "-DLINUX_DLL"
are wrong. With them, the shell tries to find and run a program named
`PLATFORM_CPPFLAGS', passing it the two arguments `=' and `-DLINUX_DLL'.
On the other hand,
PLATFORM_CPPFLAGS=-DLINUX_DLL
PLATFORM_CPPFLAGS="-DLINUX_DLL"
both define the `PLATFORM_CPPFLAGS' variable to `-DLINUX_DLL'. The double
quotes `"' in the second assignement, even if not wrong per se, are redundant,
as the assigned value (-DLINUX_DLL) does not contain spaces.
> and if not which one should work? I can only make the "no spaces and """
> work
Weird. What error do you get exactly in case (2)?
> but I see (1) in almost all documentation?
I'd guess that's documentaton referring to setting variables in Makefiles
(not shell script), where whitespaces around `=' are perfectly acceptable,
and even recommended (because they improve "visual clarity").
> TIA
> #######################################
> AM_CPPFLAGS="-DALLCOMPILES"
>
> AC_CANONICAL_HOST
> case $host in
> *linux*)
> PLATFORM_CPPFLAGS="-DLINUX_DLL"
> ;;
> *mingw*)
> PLATFORM_CPPFLAGS="-DWINDOWS_DLL"
> ;;
> esac
> AM_CPPFLAGS+=$(DEV_CPPFLAGS)
This is wrong in at least two ways:
1. It's not portable to extend a shell variable using `+=' (only a few
shells understand this construct); you should use:
VAR="$VAR foo" # good!
insted of
VAR+=" foo" # unportable!
2. I guess you want to append the value of the variable `DEV_CPPFLAGS';
but as I said above, `$(DEV_CPPFLAGS)' is not a variable expansion,
but a command subtitution.
You have to use something like this instead:
AM_CPPFLAGS="$AM_CPPFLAGS $DEV_CPPFLAGS"
> tracing_default="yes"
> AC_ARG_ENABLE(tracing,
> AS_HELP_STRING([--enable-tracing= no/yes],[if enabled all tracing
> features will be on]),
This is underquoted and badly indented; it should be e.g.:
AC_ARG_ENABLE([tracing],
[AS_HELP_STRING([--enable-tracing=no/yes],
[if enabled all tracing features will be on])],
[enable_tracing=$tracingval],
[enable_tracing=$tracing_default])
> if test "$enable_tracing" = "yes"; then
> TRACING_CPPFLAGS = -DTRACCING
This is wrong; whitespaces around `=' are not acceptable in a shell
variable's definition; just use:
TRACING_CPPFLAGS=-DTRACCING
> AC_MSG_RESULT(Enabling tracing)
Underquote; please use:
AC_MSG_RESULT([Enabling tracing])
> else
> TRACING_CPPFLAGS = -DNOTRACING
Wrong, as already explained above.
> AC_MSG_RESULT(Disabling tracing)
Underquoted, as already explained above.
> fi
> AM_CPPFLAGS+=$(TRACING_CPPFLAGS)
Wrong at least two ways, as already explained above.
>
> AC_SUBST([AM_CPPFLAGS])
> #######################################
Hope that helps,
Stefano
