automake
[Top][All Lists]
Advanced

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

Re: AM_*FLAGS and autoconf


From: Alexandre Duret-Lutz
Subject: Re: AM_*FLAGS and autoconf
Date: Wed, 16 Feb 2005 09:43:42 +0100
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

>>> "Norman" == Norman Gray <address@hidden> writes:

[...]

 Norman> Setting AM_CFLAGS is also out.  The automake
 Norman> documentation talks of this being reserved for the
 Norman> author of Makefile.am, and doesn't mention autoconf at
 Norman> all.

It's OK to AC_SUBST these if you like.  Maybe the manual ought
to speak of the "package maintainer" or anything else that does
not suggest that a "Makefile.am author" can only modify a
Makefile.am...

 Norman> The FAQ says `You should not add options to these
 Norman> variables from inside configure either', and makes a number of other
 Norman> wise suggestions which I've recently painfully discovered for myself.

"these variables" == user variables.  Is it clear from context?

 Norman> The FAQ's suggests defining differently-named variables and
 Norman> substituting them into the Makefile.am.  But this isn't really a
 Norman> solution, as it would require me to add

 Norman> AM_CFLAGS = $(MY_MAGIC_CFLAGS)
 Norman> AM_FCFLAGS = $(MY_MAGIC_FCFLAGS)
 Norman> ...

 Norman> at the top of 300+ Makefile.am files, which is exactly the sort of
 Norman> meaningless boilerplate automake is supposed to save us from.

Speaking of boilerplate, my preference would be

include $(top_srcdir)/commondefs.mk

at the top of all 300+ Makefile.am.  Sure, that means changing a
lot of files, but only once.  Then it's easy to modify the
default, and the logic of the Makefile.am will also be easier to
understand for someone reading the Makefile.am.

OTOH, I have little experience with such large trees, so maybe
AC_SUBST is more practical.

[...]

 Norman> I've also had success with modifying automake so that
 Norman> &read_main_am_file calls &define_configure_variable on all AC_SUBSTed
 Norman> AM_* variables, with the result that AM_CFLAGS+=blah will work.  This
 Norman> appears to match the intent of the preceding call to
 Norman> &define_standard_variables, so this didn't feel outrageous.

I don't understand this.  AFAICT, `AC_SUBST([AM_CPPFLAGS])'
followed by `AM_CPPFLAGS += -DFOO' works out of the box.
(Precisely because &define_standard_variables does call
&define_configure_variable for all AC_SUBSTed variables.)

[...]

--
Alexandre Duret-Lutz





reply via email to

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