[Top][All Lists]

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

Re: AM_*FLAGS and autoconf

From: Norman Gray
Subject: Re: AM_*FLAGS and autoconf
Date: 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, 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 " 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 of other Norman> wise suggestions which I've recently painfully discovered for myself.

"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 AM_CPPFLAGS.

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 files; note that in this case you will have to call AC_SUBST on the modified variable to have it appear in the''

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 and files -- may adjust these shadow variables however necessary.'' Unless you think the discussion in `Flag variables ordering' covers this adequately.

 Norman> ...

Norman> at the top of 300+ 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)/

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

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 files, and I want to keep those 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 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.)

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 useful.

Sorry for taking a while to respond -- my list subscription had been suspended by _again_, because of the proportion of thus-delivered spam our boundary mailhosts had rejected.

All the best,


Norman Gray  :  Physics & Astronomy, Glasgow University, UK  :

reply via email to

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