Re: AM_CFLAGS and %reldir%

[Thomas Martitz]

Am 14.05.2017 um 14:35 schrieb Mathieu Lirzin:
> Hello,
>
> Thomas Martitz  writes:
>>
>> If there are no other solutions, would the above idea considered if
>> someone posted a patch?
>
> I think I understand what you mean, however the issue has nothing to do
> with %reldir% which is just a convenience for not typing the current
> directory of the makefile fragment.
(unrelated, but %reldir% also enables including a fragment from more 
that one place, it's more that just convinience)


>
> The issue is that you can have only one default AM_*FLAGS per Makefile
> and when using a non-recursive Makefile (even with included fragments)
> everything is put in a unique Makefile.  When you have a lot of programs
> (for example in a test suite), having to define foo_*FLAGS for each
> program can indeed be cumbersome.
>
> I like the idea of allowing per directory default flags, I don't see any
> issue with such feature.
>
> Regarding the syntax, what about dropping the "AM" in front of
> AM_directory_*FLAGS like what is done for per programs _*FLAGS?  IIUC,
> it will be impossible to have conflicts between program and directory
> flags variables.

I think this is problematic if the fragment is included within the same 
directory, i.e. %C% expands empty (and eats the following remaining _).


Hence I suggested AM_%C%_FLAGS so it would automatically become 
AM_CFLAGS, although a AM_%C%_CFLAGS = $(AM_CFLAGS) could also be 
troublesome.


Also, I'm not planning to work on this at the moment, I'm too busy with 
other stuff at the moment. But it's good to know that the idea is 
generally sound.


Best regards.

Re: AM_CFLAGS and %reldir%

[Mathieu Lirzin]

Hello,

Thomas Martitz  writes:

> when transitioning a project to non-recursive Automake, using
> %reldir%, you lose the ability to define per-directory
> AM_{CPP,C,CXX,LD}FLAGS.
>
> With recursive Automake, you can simply set AM_CFLAGS in each
> Makefile.am. Attempting the same in a non-recursive setup would modify
> the single, global AM_CFLAGS, which may not be desirable.
>
> The only solution seems to be to heavily expand the fragments:
>
> AM_CFLAGS = -g
>
> bin_PROGRAMS = foo bar baz
>
> becomes
>
> bin_PROGRAMS += %D%/foo %D%/bar %D%/baz
>
> %C_foo_CFLAGS = -g
>
> %C_bar_CFLAGS = -g
>
> %C_baz_CFLAGS = -g
>
> (repeat for AM_CPPFLAGS, AM_CXXFLAGS, AM_LDFLAGS).
>
> This gets unwieldy in cases of many programs and libraries. As a side
> effect, Automake will emit explicit rules, making the Makefile even
> larger, though that's not much of a problem I think and is probably
> not avoidable.
>
> Is there any other solution available? I have tried to define
> directory-level AM_CFLAGS, like
>
> AM_%C%_CFLAGS = -g
>
> (applying to all targets that start with %C% after expanding) but they
> are not used.
>
>
> If there are no other solutions, would the above idea considered if
> someone posted a patch?

I think I understand what you mean, however the issue has nothing to do
with %reldir% which is just a convenience for not typing the current
directory of the makefile fragment.

The issue is that you can have only one default AM_*FLAGS per Makefile
and when using a non-recursive Makefile (even with included fragments)
everything is put in a unique Makefile.  When you have a lot of programs
(for example in a test suite), having to define foo_*FLAGS for each
program can indeed be cumbersome.

I like the idea of allowing per directory default flags, I don't see any
issue with such feature.

Regarding the syntax, what about dropping the "AM" in front of
AM_directory_*FLAGS like what is done for per programs _*FLAGS?  IIUC,
it will be impossible to have conflicts between program and directory
flags variables.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: AM_CFLAGS no longer in the manual

[Diego Elio Pettenò]

On 09/12/2012 17:32, NightStrike wrote:
 It's not more fully documented elsewhere, though.  AM_CPPFLAGS right
 about it is, however, fully documented right in this section.  This
 should be fixed, since nowhere does the manual say that AM_CFLAGS is
 -g -O2 by default.

Is it? I was confident that AM_CFLAGS is unset by default, but CFLAGS
(from autoconf) is -g -O2 by default.

And no you shouldn't change CFLAGS in configure.ac, please. That's an
user-assignable variable, distributions cry every time that we have to
patch a CFLAGS=$something in configure.ac. Especially when that's to
set/unset -O and -g flags depending on a debug/release build (hint:
distributions want debug information with optimized builds as well!).

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: AM_CFLAGS no longer in the manual

[NightStrike]

On Sun, Dec 9, 2012 at 10:44 AM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
 On 09/12/2012 17:32, NightStrike wrote:
 It's not more fully documented elsewhere, though.  AM_CPPFLAGS right
 about it is, however, fully documented right in this section.  This
 should be fixed, since nowhere does the manual say that AM_CFLAGS is
 -g -O2 by default.

 Is it? I was confident that AM_CFLAGS is unset by default, but CFLAGS
 (from autoconf) is -g -O2 by default.

 And no you shouldn't change CFLAGS in configure.ac, please. That's an
 user-assignable variable, distributions cry every time that we have to
 patch a CFLAGS=$something in configure.ac. Especially when that's to
 set/unset -O and -g flags depending on a debug/release build (hint:
 distributions want debug information with optimized builds as well!).

Obviously I'm wrong about the default.  All the more reason that it
should be documented what the default is :)

Re: AM_CFLAGS no longer in the manual

[Diego Elio Pettenò]

On 09/12/2012 23:06, Jeffrey Walton wrote:
 Seems reasonable (otherwise a stack trace is useless). Also, it does
 not affect performance. Confer: How does the gcc -g option affect
 performance? http://gcc.gnu.org/ml/gcc-help/2005-03/msg00032.html.

Correct. But in Gentoo I had to end up writing an explicit guide about
it as people (both upstream developers and users) tend to mix up the two
things: http://www.gentoo.org/proj/en/qa/backtraces.xml

Unfortunately there are a number of packages that do something like
(pseudo-autoconf — I know it's broken)

AC_ARG_ENABLE([debug], , [CFLAGS=-O0 -g3 -DDEBUG], [CFLAGS=-O2 -g0
-DNDEBUG])

which is a pain for us to manage (and we usually end up removing and
just handling the debug handling on our side.

-- 
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/

Re: AM_CFLAGS no longer in the manual

[Jeffrey Walton]

On Sun, Dec 9, 2012 at 7:14 PM, Diego Elio Pettenò
flamee...@flameeyes.eu wrote:
 On 09/12/2012 23:06, Jeffrey Walton wrote:
 Seems reasonable (otherwise a stack trace is useless). Also, it does
 not affect performance. Confer: How does the gcc -g option affect
 performance? http://gcc.gnu.org/ml/gcc-help/2005-03/msg00032.html.

 Correct. But in Gentoo I had to end up writing an explicit guide about
 it as people (both upstream developers and users) tend to mix up the two
 things: http://www.gentoo.org/proj/en/qa/backtraces.xml

 Unfortunately there are a number of packages that do something like
 (pseudo-autoconf — I know it's broken)

 AC_ARG_ENABLE([debug], , [CFLAGS=-O0 -g3 -DDEBUG], [CFLAGS=-O2 -g0
 -DNDEBUG])

 which is a pain for us to manage (and we usually end up removing and
 just handling the debug handling on our side.
Ah, I can see where that could be a problem.

Devil's advocate: what happens when projects start adding a Test
configuration (in addition to Debug and Release)? In Test, things like
private and protected are defined to public so interfaces can be
tested and state asserted?

Jeff

Re: AM_CFLAGS usage

[Norbert Sendetzky]

Hi Ralf

  Norbert Sendetzky wrote:
   This works, but as soon as I move AM_CFLAGS to the Makefile.am in the
   parent directory, they aren't set any more. Is this the way it was
   intended and the only way to set them globally is to AC_SUBST them or
   is there something wrong in my files?

 Besides the information Marc already gave you, what's wrong with
 globally setting it by AC_SUBSTing?  You can still override it per
 Makefile.am.

 Note though that
   -Wall -ansi -pedantic

 is pretty GCC specific, and will make many other compilers barf
 heavily.  So if your package targets portability, it'd be nice
 to allow your users to override these flags (preferably by
 ./configure CFLAGS='...').

How can I do this?
According to the docs, AM_CFLAGS will be overwritten by package specific flags 
but not by flags provided by the user.

Thanks


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc



pgpL8sGQvKzJd.pgp
Description: PGP signature

Re: AM_CFLAGS usage

[Ralf Corsepius]

On Mon, 2006-06-12 at 10:16 +0200, Norbert Sendetzky wrote:
 Hi Ralf
 
   Norbert Sendetzky wrote:
This works, but as soon as I move AM_CFLAGS to the Makefile.am in the
parent directory, they aren't set any more. Is this the way it was
intended and the only way to set them globally is to AC_SUBST them or
is there something wrong in my files?
 
  Besides the information Marc already gave you, what's wrong with
  globally setting it by AC_SUBSTing?  You can still override it per
  Makefile.am.
 
  Note though that
-Wall -ansi -pedantic
 
  is pretty GCC specific, and will make many other compilers barf
  heavily.  So if your package targets portability, it'd be nice
  to allow your users to override these flags (preferably by
  ./configure CFLAGS='...').
 
 How can I do this?

NOTE: CFLAGS !!

Not using AM_CFLAGS=-Wall -ansi -pedantic

and 
./configure CFLAGS=-Wall -ansi -pedantic

is what Ralf W. is referring to.

 According to the docs, AM_CFLAGS will be overwritten by package specific 
 flags 
 but not by flags provided by the user.
Nope. CFLAGS and AM_CFLAGS are being concatenated inside of a Makefile
using AM_CFLAGS.

Ralf

Re: AM_CFLAGS usage

[Norbert Sendetzky]

On Monday 12 June 2006 10:28, Ralf Corsepius wrote:
   Note though that
 -Wall -ansi -pedantic
  
   is pretty GCC specific, and will make many other compilers barf
   heavily.  So if your package targets portability, it'd be nice
   to allow your users to override these flags (preferably by
   ./configure CFLAGS='...').
 
  How can I do this?

 NOTE: CFLAGS !!

 Not using AM_CFLAGS=-Wall -ansi -pedantic

 and
 ./configure CFLAGS=-Wall -ansi -pedantic

 is what Ralf W. is referring to.

Ralf (Wildenhues) refers to OVERRIDING flags set if I understood him 
correctly. If rewrite my files to support only

./configure CFLAGS=-Wall -ansi -pedantic

these flags are never set by default if only ./configure is called.


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc



pgp5924OffuBx.pgp
Description: PGP signature

Re: AM_CFLAGS usage

[Ralf Wildenhues]

* Norbert Sendetzky wrote on Mon, Jun 12, 2006 at 11:06:36AM CEST:
 On Monday 12 June 2006 10:28, Ralf Corsepius wrote:
Note though that
  -Wall -ansi -pedantic
   
is pretty GCC specific, and will make many other compilers barf
heavily.  So if your package targets portability, it'd be nice
to allow your users to override these flags (preferably by
./configure CFLAGS='...').
  
   How can I do this?
 
  NOTE: CFLAGS !!

 Ralf (Wildenhues) refers to OVERRIDING flags set if I understood him 
 correctly.

Yes.  Maybe this should be in a FAQ or so:  you can put
  : ${CFLAGS='-Wall -ansi -pedantic'}

before AC_PROG_CC in configure.ac.  Users with non-GCC compilers won't
like you because they will have to set CFLAGS to override this, and
users (with any kind of compiler) won't like you because you take away
the default (set -g if possible, add -O2 if possible) setting they
expect from packages using Autoconf.  (I first through of
http://lists.gnu.org/archive/html/automake/2005-09/msg00108.html but
that tackles a slightly different problem setting.)

FWIW, I prefer that packages don't override CFLAGS at all.  For specific
settings, I keep a long-term build tree with a working config.status
file (and of course a config.cache as well) around.  Or a config.site
file (if you don't know what this is, read up on it in the Autoconf
manual).

Cheers,
Ralf

Re: AM_CFLAGS usage

[Norbert Sendetzky]

On Monday 12 June 2006 12:53, Ralf Wildenhues wrote:
   : ${CFLAGS='-Wall -ansi -pedantic'}

 before AC_PROG_CC in configure.ac.  Users with non-GCC compilers won't
 like you because they will have to set CFLAGS to override this, and
 users (with any kind of compiler) won't like you because you take away
 the default (set -g if possible, add -O2 if possible) setting they

OK, not the best option ;-)

 FWIW, I prefer that packages don't override CFLAGS at all.  For specific
 settings, I keep a long-term build tree with a working config.status
 file (and of course a config.cache as well) around.  Or a config.site
 file (if you don't know what this is, read up on it in the Autoconf
 manual).

Ehm, where do I find the documentation to config.site? I couldn't find it in 
the automake manual
http://sources.redhat.com/automake/automake.html

and in the autobook is only a short notice about this
http://sources.redhat.com/autobook/autobook/autobook_281.html

Google does also not reveal any useful information on the first pages.


Norbert
-- 
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc



pgpYjcZMRwCrQ.pgp
Description: PGP signature

Re: AM_CFLAGS usage

[Ralf Wildenhues]

Hello Norbert,

* Norbert Sendetzky wrote on Mon, Jun 12, 2006 at 06:42:15PM CEST:
 
 Ehm, where do I find the documentation to config.site?

Oh, sorry, I forgot to mention that config.site is an Autoconf feature.
Its manual has the information.  (The current manual isn't online, but
let's hope that changes next week...)

Cheers,
Ralf

Re: AM_CFLAGS usage

[Ralf Wildenhues]

Hello Norbert, Marc,

 Norbert Sendetzky wrote:
 
  This works, but as soon as I move AM_CFLAGS to the Makefile.am in the 
  parent 
  directory, they aren't set any more. Is this the way it was intended and 
  the 
  only way to set them globally is to AC_SUBST them or is there something 
  wrong 
  in my files?

Besides the information Marc already gave you, what's wrong with
globally setting it by AC_SUBSTing?  You can still override it per
Makefile.am.

Note though that
  -Wall -ansi -pedantic

is pretty GCC specific, and will make many other compilers barf
heavily.  So if your package targets portability, it'd be nice
to allow your users to override these flags (preferably by
./configure CFLAGS='...').

Cheers,
Ralf

Re: AM_CFLAGS not included in translation unit compilation

[Mike Mattie]

On 12/12/05, Ralf Wildenhues [EMAIL PROTECTED] wrote:
 Hi Mike,

 * Mike Mattie wrote on Sat, Dec 10, 2005 at 07:24:35PM CET:
  On 12/8/05, Ralf Wildenhues [EMAIL PROTECTED] wrote:
   * 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.

 Depends.  I would call it a bugfix rather than a regression.
 But let's be precise here.  Here's a cooked-down version of your issue:

 touch foo.c bar.c
 cat configure.ac EOF
 AC_INIT
 AM_INIT_AUTOMAKE([foo], [0.1])
 AC_PROG_CC
 AM_PROG_CC_C_O
 AC_CONFIG_FILES([Makefile])
 AC_OUTPUT
 EOF
 cat Makefile.am EOF
 AM_CFLAGS = -amcflags
 bin_PROGRAMS = foo bar
 foo_CFLAGS = -foocflags
 EOF
 aclocal
 automake -a --foreign
 autoconf
 grep -C2 CFLAGS Makefile.in

 For different Automake versions, the following happens:
 1.4:  no use of foo_CFLAGS at all.

 1.5:  foo_CFLAGS are used for compiling foo.c, but not for linking
   AM_CFLAGS used for compiling bar.c, and for linking both.

 Ditto for everything up to 1.9.6 (I believe).

 1.9a: AM_CFLAGS used for compiling and linking bar,
   foo_CFLAGS used for compiling and linking foo.

 Never are foo_CFLAGS and AM_CFLAGS used *both* on the same command line.
 This corresponds to the fact that with many compilers, compilation flags
 are not easily overridable, and the primary intended use of foo_CFLAGS
 was to give the developer a way to override AM_CFLAGS (I think).

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

 I don't think server.o would ever be used to create sever-server.o.
 Automake never issues incremental linking rules itself.  Maybe you
 meant
   server 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.

 Well, I don't see any automake version where it would have worked this
 way, in that AM_CFLAGS would have been used during compilation.  Except
 for when foo_CFLAGS wasn't supported at all.

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

 Yes.  AM_CFLAGS and AM_LDFLAGS clearly do have different use though.

  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.

 Do you still think this?

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

 Can't answer that, but I still don't see the way it regresses.  Sorry.

 Cheers,
 Ralf


I am following now, foo_CFLAGS blows away AM_CFLAGS . thanks for the
help in understanding this. I will simply reference AM_CFLAGS in
foo_CFLAGS when I want to
combine the two.

thanks again for helping me understand this.

Re: AM_CFLAGS not included in translation unit compilation

[Ralf Wildenhues]

Hi Mike,

* Mike Mattie wrote on Sat, Dec 10, 2005 at 07:24:35PM CET:
 On 12/8/05, Ralf Wildenhues [EMAIL PROTECTED] wrote:
  * 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.

Depends.  I would call it a bugfix rather than a regression.
But let's be precise here.  Here's a cooked-down version of your issue:

touch foo.c bar.c
cat configure.ac EOF
AC_INIT
AM_INIT_AUTOMAKE([foo], [0.1])
AC_PROG_CC
AM_PROG_CC_C_O
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
EOF
cat Makefile.am EOF
AM_CFLAGS = -amcflags
bin_PROGRAMS = foo bar
foo_CFLAGS = -foocflags
EOF
aclocal
automake -a --foreign
autoconf
grep -C2 CFLAGS Makefile.in

For different Automake versions, the following happens:
1.4:  no use of foo_CFLAGS at all.

1.5:  foo_CFLAGS are used for compiling foo.c, but not for linking
  AM_CFLAGS used for compiling bar.c, and for linking both.

Ditto for everything up to 1.9.6 (I believe).

1.9a: AM_CFLAGS used for compiling and linking bar,
  foo_CFLAGS used for compiling and linking foo.

Never are foo_CFLAGS and AM_CFLAGS used *both* on the same command line.
This corresponds to the fact that with many compilers, compilation flags
are not easily overridable, and the primary intended use of foo_CFLAGS
was to give the developer a way to override AM_CFLAGS (I think).

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

I don't think server.o would ever be used to create sever-server.o.
Automake never issues incremental linking rules itself.  Maybe you
meant 
  server 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.

Well, I don't see any automake version where it would have worked this
way, in that AM_CFLAGS would have been used during compilation.  Except
for when foo_CFLAGS wasn't supported at all.

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

Yes.  AM_CFLAGS and AM_LDFLAGS clearly do have different use though.

 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.

Do you still think this?

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

Can't answer that, but I still don't see the way it regresses.  Sorry.

Cheers,
Ralf

Re: AM_CFLAGS not included in translation unit compilation

[Mike Mattie]

On 12/8/05, Ralf Wildenhues [EMAIL PROTECTED] 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

Re: AM_CFLAGS not included in translation unit compilation

[Ralf Wildenhues]

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

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.

Cheers,
Ralf

Re: AM_CFLAGS in the project root?

[Alexandre Duret-Lutz]

 Baurjan == Baurjan Ismagulov [EMAIL PROTECTED] writes:

[...]
 Baurjan I can do this by defining AM_CFLAGS in each
 Baurjan subdirectory. This works. However, I want to have it
 Baurjan in one place. So I've tried to define this variable in
 Baurjan the root directory instead of subdirectories, but in
 Baurjan this case the generated Makefiles don't seem to use
 Baurjan it. 

Only the root directory would use it, since variables defined in
Makefile.ams are not inherited between Makefile.ams.

However you probably know that variables AC_SUBSTed in
configure.ac are defined in all Makefiles.  So you could
define AM_CFLAGS in all your Makefiles using
  AC_SUBST([AM_CFLAGS], [value])
in configure.ac.

Note that Makefile.am definitions still have priority over
configure.ac AC_SUBSTs.  Therefore you can use AC_SUBST
to give AM_CFLAGS a global default value, and override this
definition locally in a Makefile.am if needed.
-- 
Alexandre Duret-Lutz

Re: AM_CFLAGS in the project root?

[Baurjan Ismagulov]

Hello, Alexandre!

On Fri, Jun 18, 2004 at 08:18:33PM +0200, Alexandre Duret-Lutz wrote:
   AC_SUBST([AM_CFLAGS], [value])

Thank you, this works! I did read about AC_SUBST, but haven't thought
about using it that way.

With kind regards,
Baurjan.

Re: AM_CFLAGS and sub/foo.c

[Alexandre Oliva]

On Jun 15, 2001, Steve M. Robbins [EMAIL PROTECTED] wrote:

 I normally want the program-specific flags _in addition_ to the
 generic flags.  So I *always* have $(LDADD) in $foo_LDADD.

But consider the case of not wanting $(LDADD) in foo_LDADD.  Or
consider cases in which the order matters, and you need control over
where $(LDADD) appears in foo_LDADD.  I think the only way to do this
right is to defer the decision to the user, which means not having it
included by default.  Which is a good thing in itself, because it lets
one omit LDADD completely.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me

Re: AM_CFLAGS and sub/foo.c

[Tom Tromey]

 Steve == Steve M Robbins [EMAIL PROTECTED] writes:

Steve Given the following Makefile.am
Steve  bin_PROGRAMS = foo
Steve  foo_SOURCES = foo.c sub/foo2.c
Steve it turns out that foo.c is compiled using $(COMPILE), and hence
Steve includes AM_CFLAGS.  However, foo2.c is compiled *without*
Steve AM_CFLAGS.

Thanks for noticing this!

What I intended is that by default everything is compiled with
AM_CFLAGS.  But if there are per-executable CFLAGS in effect, then
AM_CFLAGS is omitted.  So I agree you've found a bug.

Your message, plus my recent adventures into automake.texi, make me
wonder if this is the best approach.  It would certainly be easier to
document if AM_CFLAGS was simply always used.

Now is the time to decide this sort of thing -- before 1.5 goes out.
Any comments?  Reasons to prefer one over the other?  As I recall I
planned it this way on the theory that adding AM_CFLAGS to the per-exe
CFLAGS is easy for the user, but removing it would be hard.

Tom

Re: AM_CFLAGS and sub/foo.c

[Tom Tromey]

 Steve == Steve M Robbins [EMAIL PROTECTED] writes:

Steve The upshot is that foo.c is compiled using AM_CFLAGS but NOT
Steve foo_CFLAGS, while foo2.c is compiled NOT using AM_CFLAGS but using
Steve foo_CFLAGS.

I'm checking in a fix for this.

Tom

Re: AM_CFLAGS and sub/foo.c

[Steve M. Robbins]

On Thu, Jun 14, 2001 at 06:51:09PM -0600, Tom Tromey wrote:
  Steve == Steve M Robbins [EMAIL PROTECTED] writes:
 
 Steve Given the following Makefile.am
 Stevebin_PROGRAMS = foo
 Stevefoo_SOURCES = foo.c sub/foo2.c
 Steve it turns out that foo.c is compiled using $(COMPILE), and hence
 Steve includes AM_CFLAGS.  However, foo2.c is compiled *without*
 Steve AM_CFLAGS.
 
 Thanks for noticing this!
 
 What I intended is that by default everything is compiled with
 AM_CFLAGS.  But if there are per-executable CFLAGS in effect, then
 AM_CFLAGS is omitted.  So I agree you've found a bug.
 
 Your message, plus my recent adventures into automake.texi, make me
 wonder if this is the best approach.  It would certainly be easier to
 document if AM_CFLAGS was simply always used.
 
 Now is the time to decide this sort of thing -- before 1.5 goes out.
 Any comments?  Reasons to prefer one over the other?  As I recall I
 planned it this way on the theory that adding AM_CFLAGS to the per-exe
 CFLAGS is easy for the user, but removing it would be hard.

So what you are saying is that AM_CFLAGS and foo_CFLAGS will behave
like LDADD and foo_LDADD (i.e. setting the foo_ version overrides the
other)?

I've always found this a bit of a nuisance with LDADD, to be honest.
I normally want the program-specific flags _in addition_ to the
generic flags.  So I *always* have $(LDADD) in $foo_LDADD.

I see that you've already checked in a fix: thanks!

-Steve

-- 
by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Re: AM_CFLAGS

[Tom Tromey]

 "Akim" == Akim Demaille [EMAIL PROTECTED] writes:

Akim ifdef([m4_pattern_allow],
Akim   [m4_pattern_allow([^AM_CFLAGS$])])dnl

Feel free to check in this change if you get to it before I do.

Tom

Re: AM_CFLAGS

[Akim Demaille]

Alexandre Oliva [EMAIL PROTECTED] writes:

 On Feb 13, 2001, Tom Tromey [EMAIL PROTECTED] wrote:
 
  I don't want to remove anything from autoconf's blacklist.  Doing that
  means we have to update autoconf whenever we change automake.
 
 Nope.  CVS Autoconf has a macro to remove strings from the blacklist.
 
 ifdef([m4_pattern_allow],[m4_pattern_allow([AM_CFLAGS])])
 
 will let you refer to AM_CFLAGS in configure.in without introducing
 any dependency on CVS autoconf.

Let me nitpick a bit:

ifdef([m4_pattern_allow],
  [m4_pattern_allow([^AM_CFLAGS$])])dnl

(note the anchors too).  I insist on the dnl: currently automake dump
a long series of empty lines coming from there.  And BTW, instead of

# Autoconf 2.50 wants to disallow AM_ names.  We explicitly allow
# the ones we care about.
ifdef([m4_pattern_allow], [m4_pattern_allow([AM_CFLAGS])])
ifdef([m4_pattern_allow], [m4_pattern_allow([AM_CPPFLAGS])])
ifdef([m4_pattern_allow], [m4_pattern_allow([AM_CXXFLAGS])])
ifdef([m4_pattern_allow], [m4_pattern_allow([AM_OBJCFLAGS])])
ifdef([m4_pattern_allow], [m4_pattern_allow([AM_FFLAGS])])
ifdef([m4_pattern_allow], [m4_pattern_allow([AM_RFLAGS])])
ifdef([m4_pattern_allow], [m4_pattern_allow([AM_GCJFLAGS])])

you can

# Autoconf 2.50 wants to disallow AM_ names.  We explicitly allow
# the ones we care about.
ifdef([m4_pattern_allow],
  [m4_pattern_allow([^AM_(C|CPP|CXX|OBJC|F|R|GCJ)FLAGS$])])dnl

Re: AM_CFLAGS

[Tom Tromey]

 "Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:

 In the recent namespace conversation we didn't mention macros like
 `AM_CFLAGS'.  This is an automake-specific macro which the user is
 allowed to set.

 How should we rename these?

Alexandre Why should we rename these?  Their names look fine to me.

My understanding is that autoconf prevents us from putting these names
(AM_*) into configure.in.  However, this is a perfectly reasonable
thing to do from automake's perspective.  In fact, it is probably a
preferred approach for packages with special flags requirements and
multiple directories.

Tom

Re: AM_CFLAGS

[Alexandre Oliva]

On Feb 12, 2001, Tom Tromey [EMAIL PROTECTED] wrote:

 My understanding is that autoconf prevents us from putting these names
 (AM_*) into configure.in.

We can remove specific items from autoconf's blacklist.  Anyway, the
variables you mentioned are Makefile variables, not generally listed
in configure.in.  What am I missing?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me

Re: AM_CFLAGS

[Alexandre Oliva]

On Feb 12, 2001, Steve Robbins [EMAIL PROTECTED] wrote:

 And I thought that it was a simple bug: the aclocal regexp was not
 taking into account the possibility of assigning to a variable name
 starting with "AM_".

You shouldn't assign to these variables.  These are for *users* to
override, not for configure.in to override.  It's good that aclocal
and autoconf won't let you do it easily.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me

Re: AM_CFLAGS

[Steve Robbins]

On Tue, Feb 13, 2001 at 01:14:31AM -0200, Alexandre Oliva wrote:
 On Feb 12, 2001, Steve Robbins [EMAIL PROTECTED] wrote:
 
  And I thought that it was a simple bug: the aclocal regexp was not
  taking into account the possibility of assigning to a variable name
  starting with "AM_".
 
 You shouldn't assign to these variables.  These are for *users* to
 override, not for configure.in to override.  It's good that aclocal
 and autoconf won't let you do it easily.

Hm.  I didn't check the archives, but I'm pretty sure this discussion
has already taken place on at least one of the two auto* lists.

My recollection of that discussion was just the opposite: the user
gets to set CFLAGS, LDFLAGS, and the like, while the software author
gets to set AM_-versions of them.  Otherwise, why have two versions
of them?

Cheers,
-Steve

Re: AM_CFLAGS

[Tom Tromey]

 "Alexandre" == Alexandre Oliva [EMAIL PROTECTED] writes:

 My understanding is that autoconf prevents us from putting these
 names (AM_*) into configure.in.

Alexandre We can remove specific items from autoconf's blacklist.
Alexandre Anyway, the variables you mentioned are Makefile variables,
Alexandre not generally listed in configure.in.  What am I missing?

A macro like AM_CFLAGS is intended to be used by the Makefile.am
writer to pass flags to the compilation.  It is entirely reasonable to
set this in configure.in and then AC_SUBST it.

I don't want to remove anything from autoconf's blacklist.  Doing that
means we have to update autoconf whenever we change automake.

Tom

Re: AM_CFLAGS

[Alexandre Oliva]

On Feb 13, 2001, Tom Tromey [EMAIL PROTECTED] wrote:

 I don't want to remove anything from autoconf's blacklist.  Doing that
 means we have to update autoconf whenever we change automake.

Nope.  CVS Autoconf has a macro to remove strings from the blacklist.

ifdef([m4_pattern_allow],[m4_pattern_allow([AM_CFLAGS])])

will let you refer to AM_CFLAGS in configure.in without introducing
any dependency on CVS autoconf.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me

Re: AM_CFLAGS

[Alexandre Oliva]

On Feb 11, 2001, Tom Tromey [EMAIL PROTECTED] wrote:

 In the recent namespace conversation we didn't mention macros like
 `AM_CFLAGS'.  This is an automake-specific macro which the user is
 allowed to set.

 How should we rename these?

Why should we rename these?  Their names look fine to me.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me