Re: AM_*FLAGS and autoconf

[Norman Gray]

Greetings,

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
>  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?

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

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 
> 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 lists.gnu.org _again_, because of the proportion of 
thus-delivered spam our boundary mailhosts had rejected.

All the best,

Norman


--
----------------------------------------------------------------------
Norman Gray  :  Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/  :  www.starlink.ac.uk