Re: [Andrew Suffield <address@hidden>] Bug#157887: autoconf: various imperfectly formed functions in c.m4

[Harlan Stenn]

> > I'm working on one application where the package Requires gcc, and the
> > design spec Requires "-Wall -Werror".
> 
> Weird -- the design spec requires you to be slaves to the GCC police?

I'm on the build team.  I can see their point, however.  And the Linux
kernel portion of the build is exempt from this requirement (as are one or
two 3rd-party products).

> But anyway, surely it the spec requires this only of your program, not
> of your "configure" script's contents.  So you should be able to put
> -Wall -Werror in AM_CFLAGS or something like that.

There are many hundreds of Makefile.am's on this project.  We set "global
policy" in the configure script.

We don't actually use "configure" for much more than setting variables that
need to be set in the Makefile.am's, spitting out the Makefile's, and
running some scripts as part of a config.status run.

> > However, with 2.54 I am now seeing message about how I should't be using
> > CFLAGS (or a whole bunch of others), but should be using the AM_ versions
> > instead.
> 
> As far as I know, Autoconf doesn't know or worry about AM_CFLAGS.
> That's Automake's job.  Perhaps you've run into an interoperability
> problem (wouldn't be the first time), but I'd like to know details
> about how to reproduce it.

I'm not sure myself yet - it may have something to do with an AC_SUBST() of
one of the variables.

> > So what's the preferred way to write software that uses automake and
> > autoconf given that some of these variables need to be amended during the
> > configure process?

> The preferred way is to not amend them during the configure process,
> but to amend them (if needed) during the build.  It has never been
> that portable to assign to CFLAGS at random points in your configure
> script.  (I know, I know, I've done it myself -- but I've usually
> regretted it afterwards.0

Perhaps "amended" was the wrong word.

This product/package needs to have certain variables (CFLAGS, LDFLAGS,
INCLUDES, etc.) take certain extra values to get the generated software to
build/install "properly".

The product/package was using a hacked automake-1.5, a hacked libtool-1.4.2,
and a stock autoconf.

I'm trying to remove as many of these hacks/bugfixes as possible, and it
looks like upgrading to 2.54 and 1.7 will get me very close to that.

Along the way, however, both automake and autoconf are finding previously
undetected "problems" with the Makefile.am's and some of these "user
variables".

I need a way to implement this cleanup and conversion that (preferably)
works for both automake-1.5 and -1.7.

I may have to postpone the AM_userVar conversion until later.

H