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 configure.ac.
For such things, it is VERY useful to add something like this: include $(top_srcdir)/Makefile.common at the top of every Makefile.am. 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 Makefile.am. 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 > (http://www.mail-archive.com/automake@gnu.org/msg10024.html) but could > not understand quite what I was supposed to do. Put this into your configure.ac: AC_SUBST(AM_CPPFLAGS) (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 compilation. 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 configure.ac, 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. Jirka ------------------------ AC_DEFUN(MY_CXX_OPTION, [AC_MSG_CHECKING([for $2]) AC_CACHE_VAL(epos_cv_cxx_opt_$1, [ cat > conftest.cc <<EOF #include <stdio.h> int main(int argc, char **argv) { argc=argc; argv=argv; return 0; } EOF epos_cv_cxx_opt_$1="" for opt in $3; do if test -z "${epos_cv_cxx_opt_$1}"; then if ${CXX} ${opt} -o conftest conftest.cc 2>conftest2 1>&5; then if test -f conftest2; then msg=`cat conftest2` if test -z "${msg}"; then epos_cv_cxx_opt_$1=${opt} fi else epos_cv_cxx_opt_$1=${opt} fi fi fi done if test -z "${epos_cv_cxx_opt_$1}"; then epos_cv_cxx_opt_$1="unknown" fi rm -f conftest conftest2]) if test "${epos_cv_cxx_opt_$1}" = "unknown"; then AC_MSG_RESULT("unknown") $1="" else AC_MSG_RESULT(${epos_cv_cxx_opt_$1}) $1=${epos_cv_cxx_opt_$1} fi]) Jirka
