[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AM_*FLAGS and autoconf
Re: AM_*FLAGS and autoconf
Fri, 18 Feb 2005 16:30:13 +0000
On 2005 Feb 16 , at 09:43, Alexandre Duret-Lutz wrote:
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
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
Norman> The FAQ says `You should not add options to these
Norman> variables from inside configure either', and makes a number
Norman> wise suggestions which I've recently painfully discovered for
"these variables" == user variables. Is it clear from context?
Ah right -- no, I took quite the opposite meaning, since the sentence
with `these variables' appears right after an example showing setting
How about this as a replacement for that paragraph:
``You should not add options to these user variables within configure
either, for the same reason. Occasionally you need to modify these
variables to perform a test, but you should reset their values
afterwards. In contrast, it is OK to modify the AM_* variables within
configure, but it is rather rare that you need to do this, unless you
are writing a macro which might appear in multiple configure.ac files;
note that in this case you will have to call AC_SUBST on the modified
variable to have it appear in the Makefile.in.''
That leads into the `What we recommend...' paragraph.
In the section `Variables reserved for the user', it _might_ be worth
adding something explicit such as ``...for YFLAGS is AM_YFLAGS. The
package maintainer -- that is, the author(s) of the Makefile.am and
configure.ac files -- may adjust these shadow variables however
necessary.'' Unless you think the discussion in `Flag variables
ordering' covers this adequately.
Norman> AM_CFLAGS = $(MY_MAGIC_CFLAGS)
Norman> AM_FCFLAGS = $(MY_MAGIC_FCFLAGS)
Norman> at the top of 300+ Makefile.am files, which is exactly the
Norman> meaningless boilerplate automake is supposed to save us from.
Speaking of boilerplate, my preference would be
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.
I hadn't thought of this include technique, but I think I'm going to
stick with the AC_SUBST. The author of the various macros fiddling
with AM_* (me) is not (always) the same as the authors of the
Makefile.am files, and I want to keep those Makefile.am files looking
as `normal' as possible, so that folk can refer to the standard
automake documentation except when they clearly have to look at my
documentation, for one of `my' macros. Put another way, I want to add
macros, but add no idioms.
Of course, this way I do have to remind folk to redefine AM_* using +=
rather than =, but that's a warning rather than a change.
Norman> I've also had success with modifying automake so that
Norman> &read_main_am_file calls &define_configure_variable on all
Norman> AM_* variables, with the result that AM_CFLAGS+=blah will
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.)
Sorry, this was brain-fade. AM_XXX += -DFOO does indeed work out of
the box -- the gotcha was that the AM_* variables (or at least
AM_FCFLAGS, which is the one I principally care about) aren't
AC_SUBSTed by default, so the &define_configure_variable wasn't
defining it. Clearly the one of many combinations I never actually
tried was AC_SUBST plus '+='. Hence the final remark in the suggested
alternative paragraph above.
Thanks for your help, Alexandre -- I hope the suggested text above is
Sorry for taking a while to respond -- my list subscription had been
suspended by lists.gnu.org _again_, because of the proportion of
thus-delivered spam our boundary mailhosts had rejected.
All the best,
Norman Gray : Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk