automake
[Top][All Lists]
Advanced

[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


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





reply via email to

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