[Top][All Lists]

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

Re: AM_CFLAGS not included in translation unit compilation

From: Mike Mattie
Subject: Re: AM_CFLAGS not included in translation unit compilation
Date: Sat, 10 Dec 2005 10:24:35 -0800

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?

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.


then I have this:


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

$(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

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

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

> Cheers,
> Ralf

reply via email to

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