Re: AM_CFLAGS not included in translation unit compilation

[Mike Mattie]

On 12/8/05, Ralf Wildenhues <address@hidden> wrote:
> Hi Mike,
>
> * Mike Mattie wrote on Fri, Dec 09, 2005 at 12:59:33AM CET:
> >
> > In a recent project I noticed that the individual compilation units do
> > not include AM_CFLAGS in the invocation of the compiler, however
> > when the program is constructed in the linking phase the AM_CFLAGS
> > variable is used. Is there a rational for this ? I would like
> > to place debugging (-g) in AM_CFLAGS and instead I am placing it in 
> > prog_CFLAGS.
>
> Does reading this chapter of the documentation answer your question?
> http://sources.redhat.com/automake/automake.html#Flag-Variables-Ordering

actually it makes me think even more that my automake (1.9.6) has a
regression against
the behavior of previous releases and the documentation.

here is a bit more detail without being too verbose. in AM_CFLAGS i
wanted a debug
option like so, in this perticular project all targets should have
debugging symols.

AM_CFLAGS=-g

then I have this:

server_SOURCES=server.c

automake invokes the compiler twice. Once to create server-server.o
from server.c.
*in this* compilation AM_CFLAGS is ommited. I grepped this from the
Makefile created
by autoconf/automake

        if $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS)
$(CPPFLAGS) $(server_CFLAGS) $(CFLAGS) -MT server-server.o -MD -MP -MF
"$(DEPDIR)/server-server.Tpo" -c -o server-server.o `test -f
'server.c' || echo '$(srcdir)/'`server.c;
...

AM_CFLAGS is clearly missing. however AM_CFLAGS is referanced when
server.o is linked from sever-server.o

I think this is clearly wrong. I have a older autotools project from
2003 where I clearly relied on compiler flags for translation units
being referenced from AM_CFLAGS across the entire
project.

If I wished to include flags at the link phase only I would choose
_LDFLAGS after reading the documentation.

> I point to the online version rather than the info document because I
> believe Alexandre expanded this part not too long ago, and it's much
> clearer now.

I think the above demonstrates that it is not a ordering issue, rather
that a variable that should be included in a compilation is missing
altogether.

What I need to know is will the upstream maintainers call this one as a bug ?

> Cheers,
> Ralf
>