Re: Setting libXXX_la_CPPFLAGS and libXXX_la_CFLAGS erases AM_CPPFLAGS and AM_CFLAGS
On Saturday 2022-11-19 09:11, madmurphy wrote: >I guess it does make sense. But then what might be missing to Automake are >libXXX_la_AM_CFLAGS, libXXX_la_AM_CPPFLAGS and libXXX_la_AM_LDFLAGS >variables, in which the global AM_CFLAGS, AM_CPPFLAGS and AM_LDFLAGS are >automatically pasted (whereas the corresponding versions without the AM_ >prefix erase everything)… I guess it's doable. But probably not worth the development effort or the codebase impact.
Re: Setting libXXX_la_CPPFLAGS and libXXX_la_CFLAGS erases AM_CPPFLAGS and AM_CFLAGS
I guess it does make sense. But then what might be missing to Automake are libXXX_la_AM_CFLAGS, libXXX_la_AM_CPPFLAGS and libXXX_la_AM_LDFLAGS variables, in which the global AM_CFLAGS, AM_CPPFLAGS and AM_LDFLAGS are automatically pasted (whereas the corresponding versions without the AM_ prefix erase everything)… --madmurphy On Fri, Nov 18, 2022 at 11:42 PM Jan Engelhardt wrote: > > On Friday 2022-11-18 22:57, Russ Allbery wrote: > >madmurphy writes: > > > >> However, if at the same time I set also the libfoo_la_CPPFLAGS variable > (no > >> matter the content), as in the following example, > > > >> AM_CPPFLAGS = \ > >> "-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\"" > >> libfoo_la_CPPFLAGS = \ > >> "-DLIBFOO_DUMMY=\"This is just a dummy text\"" > > > >> the AM_CPPFLAGS variable will be completely overwritten > > It makes sense though. > > It's better that pertarget_CPPFLAGS overwrites, because otherwise... there > would be no chance to dump (get rid) the AM_CPPFLAGS portion in the > command-line - short of never setting AM_CPPFLAGS at all, which is not very > economical if all you want to change is one target... >
Re: Setting libXXX_la_CPPFLAGS and libXXX_la_CFLAGS erases AM_CPPFLAGS and AM_CFLAGS
On Friday 2022-11-18 22:57, Russ Allbery wrote: >madmurphy writes: > >> However, if at the same time I set also the libfoo_la_CPPFLAGS variable (no >> matter the content), as in the following example, > >> AM_CPPFLAGS = \ >> "-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\"" >> libfoo_la_CPPFLAGS = \ >> "-DLIBFOO_DUMMY=\"This is just a dummy text\"" > >> the AM_CPPFLAGS variable will be completely overwritten It makes sense though. It's better that pertarget_CPPFLAGS overwrites, because otherwise... there would be no chance to dump (get rid) the AM_CPPFLAGS portion in the command-line - short of never setting AM_CPPFLAGS at all, which is not very economical if all you want to change is one target...
Re: Setting libXXX_la_CPPFLAGS and libXXX_la_CFLAGS erases AM_CPPFLAGS and AM_CFLAGS
madmurphy writes: > However, if at the same time I set also the libfoo_la_CPPFLAGS variable (no > matter the content), as in the following example, > AM_CPPFLAGS = \ >"-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\"" > ... > libfoo_la_CPPFLAGS = \ >"-DLIBFOO_DUMMY=\"This is just a dummy text\"" > the AM_CPPFLAGS variable will be completely overwritten by the > libfoo_la_CPPFLAGS variable, and invoking libfoo_func() will print > Message from the build system: undefined While this is often confusing, this is the documented behavior of Automake. See: https://www.gnu.org/software/automake/manual/automake.html#Program-and-Library-Variables In compilations with per-target flags, the ordinary ‘AM_’ form of the flags variable is not automatically included in the compilation (however, the user form of the variable is included). So for instance, if you want the hypothetical maude compilations to also use the value of AM_CFLAGS, you would need to write: maude_CFLAGS = … your flags … $(AM_CFLAGS) See Flag Variables Ordering, for more discussion about the interaction between user variables, ‘AM_’ shadow variables, and per-target variables. and https://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering -- Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>
Setting libXXX_la_CPPFLAGS and libXXX_la_CFLAGS erases AM_CPPFLAGS and AM_CFLAGS
Hi,
If I create a library named libfoo containing the following code (example
attached),
#include "libfoo.h"
#ifndef LIBFOO_BUILD_MESSAGE
#define LIBFOO_BUILD_MESSAGE "undefined"
#endif
int libfoo_func() {
printf("Message from the build system: " LIBFOO_BUILD_MESSAGE "\n");
return 0;
}
and then I set the LIBFOO_BUILD_MESSAGE preprocessor macro via Makefile.am,
AM_CPPFLAGS = \
"-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\""
invoking libfoo_func() from a linked program will correctly print the
following text.
Message from the build system: correctly defined via AM_CPPFLAGS
However, if at the same time I set also the libfoo_la_CPPFLAGS variable (no
matter the content), as in the following example,
AM_CPPFLAGS = \
"-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\""
...
libfoo_la_CPPFLAGS = \
"-DLIBFOO_DUMMY=\"This is just a dummy text\""
the AM_CPPFLAGS variable will be completely overwritten by the
libfoo_la_CPPFLAGS variable, and invoking libfoo_func() will print
Message from the build system: undefined
If I decide to use the *_CFLAGS class of variables instead of *_CPPFLAGS,
AM_CFLAGS = \
-Wall \
-Wextra \
-g \
"-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\""
...
libfoo_la_CFLAGS = \
"-DLIBFOO_DUMMY=\"This is just a dummy text\""
the result will be the same.
Message from the build system: undefined
To restore AM_CPPFLAGS (or AM_CFLAGS) I need to mention it explicitly in
libfoo_la_CPPFLAGS.
AM_CPPFLAGS = \
"-DLIBFOO_BUILD_MESSAGE=\"correctly defined via AM_CPPFLAGS\""
...
libfoo_la_CPPFLAGS = \
$(AM_CPPFLAGS) \
"-DLIBFOO_DUMMY=\"This is just a dummy text\""
In this case libfoo_func() will correctly print
Message from the build system: correctly defined via AM_CPPFLAGS
Is this a wanted behavior? Isn't the sense of AM_* variables that of being
applied to every single library in a project?
--madmurphy
libfoo-1.0.0.tar.xz
Description: application/xz
Re: AM_CFLAGS and %reldir%
Am 14.05.2017 um 14:35 schrieb Mathieu Lirzin: > Hello, > > Thomas Martitz <ku...@rockbox.org> 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%
Hello,
Thomas Martitz <ku...@rockbox.org> 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
AM_CFLAGS and %reldir%
Hello,
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?
Best regards.
AM_CFLAGS no longer in the manual
I was looking in the manual to see what the default definition of AM_CFLAGS was. It's gone. Instead, all I see is this: AM_CFLAGS This is the variable the Makefile.am author can use to pass in additional C compiler flags. It is more fully documented elsewhere. In some situations, this is not used, in preference to the per-executable (or per-library) _CFLAGS. 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.
Re: AM_CFLAGS no longer in the manual
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
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
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
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: AC_PROG_CC sets CFLAGS, what about AM_CFLAGS?
() Benoit SIGOURE [EMAIL PROTECTED] () Mon, 27 Aug 2007 21:12:28 +0200 OK look, here is how it goes AFAIK: - You want to set project-wide flags, use AM_CFLAGS - Your user wants to set project-wide flags, it does: ./configure CFLAGS=... - If your user didn't set project-wide flags, AM_PROG_CC may put some default flags in CFLAGS (that can be safely overridden by the user) What's wrong with this? i don't think anything is wrong with how it is SUPPOSED to work (which i understand, but which you do not seem to understand that i understand). don't worry about it. thi
Re: AC_PROG_CC sets CFLAGS, what about AM_CFLAGS?
Beniot wrote: OK look, here is how it goes AFAIK: - You want to set project-wide flags, use AM_CFLAGS - Your user wants to set project-wide flags, it does: ./configure CFLAGS=... - If your user didn't set project-wide flags, AM_PROG_CC may put some default flags in CFLAGS (that can be safely overridden by the user) What's wrong with this? It gives the user more things to type. H
AC_PROG_CC sets CFLAGS, what about AM_CFLAGS?
() Benoit SIGOURE [EMAIL PROTECTED] () Mon, 27 Aug 2007 09:48:16 +0200 AM_CFLAGS is reserved for developers. It's not a problem if the user overrides the default value of CFLAGS since CFLAGS is reserved for the user. i understand, and am actually trying achieve, this. my point is that it is the auto* tools themselves that are not helping, or at least i don't know how to request their help to arrange for a situation where AM_CFLAGS is reserved for developers. what i see is that configure sets CFLAGS and *not* AM_CFLAGS, in apparently normal usage. it seems a contradiction between what is espoused in the docs and what actually happens. however, i see libtool is not directly culpable, so i cc automake folks, instead, and change the subject line. thi
Re: AC_PROG_CC sets CFLAGS, what about AM_CFLAGS?
On Aug 27, 2007, at 2:51 PM, Thien-Thi Nguyen wrote: () Benoit SIGOURE [EMAIL PROTECTED] () Mon, 27 Aug 2007 09:48:16 +0200 AM_CFLAGS is reserved for developers. It's not a problem if the user overrides the default value of CFLAGS since CFLAGS is reserved for the user. i understand, and am actually trying achieve, this. my point is that it is the auto* tools themselves that are not helping, or at least i don't know how to request their help to arrange for a situation where AM_CFLAGS is reserved for developers. what i see is that configure sets CFLAGS and *not* AM_CFLAGS, in apparently normal usage. it seems a contradiction between what is espoused in the docs and what actually happens. OK look, here is how it goes AFAIK: - You want to set project-wide flags, use AM_CFLAGS - Your user wants to set project-wide flags, it does: ./configure CFLAGS=... - If your user didn't set project-wide flags, AM_PROG_CC may put some default flags in CFLAGS (that can be safely overridden by the user) What's wrong with this? -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory PGP.sig Description: This is a digitally signed message part
Re: AM_CFLAGS usage
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
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
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
* 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
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
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
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
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
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
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
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
AM_CFLAGS not included in translation unit compilation
Hello automake mailing list, 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.
Re: AC_DEFINE_DIR in autoconf (was: Re: SYSCONFDIR: config.h vs. AM_CFLAGS)
On Wed, Mar 09, 2005 at 08:06:18PM +0100, Baurjan Ismagulov wrote: What I don't understand is why the manual states that AC_DEFINE_DIR does not conform with GNU codings standards. If I define DATADIR in CPPFLAGS, it is hard-coded into the binary, and the user can override the prefix during make install. This behaviour is not declared non-conforming. If you set CPPFLAGS=$CPPFLAGS -DDATADIR='\$(datadir)' or CPPFLAGS=$CPPFLAGS '-DDATADIR=$(datadir)' in your configure.ac, then the $(datadir) part is expanded by make. So you can do ./configure --prefix=oneprefix make prefix=anotherprefix make prefix=yetanother install Your config.h approach doesn't allow the user to redifine prefix for make all, even though it allows them to redefine it for make install. (Not that I know what is this requirment good for. I don't advocate the standard, I just explain what conforms to it and what doesn't.) Have a nice day, Stepan
AC_DEFINE_DIR in autoconf (was: Re: SYSCONFDIR: config.h vs. AM_CFLAGS)
[Taking the discussion to the autoconf list.] On Mon, Mar 07, 2005 at 09:57:31AM -0400, Leonardo Boiko wrote: Isn't config.h created at configure time? AFAIK directory installation variables should only be defined at make time. See ``info Autoconf Installation Directory Variables''. I had read these sections before posting, but I understand them only now :) . What I don't understand is why the manual states that AC_DEFINE_DIR does not conform with GNU codings standards. If I define DATADIR in CPPFLAGS, it is hard-coded into the binary, and the user can override the prefix during make install. This behaviour is not declared non-conforming. If I define DATADIR in config.h, it is hard-coded into the binary, and the user can override the prefix during make install. The section 7.2.4 of GCS states that prefix should be redefinable by installers via make or configure. I couldn't find a place where it requires that make prefix=xxx should cause hard-coding of the new prefix, so I fail to see why AC_DEFINE_DIR is declared non-compliant. I would really like that AC_DEFINE_DIR is included in automake, thus making config.h the single compilation configuration file. Comments? Maybe you could use instead a dedicated header, created through the Makefile. See ``info Autoconf Defining Directories''.[2] I would ideally prefer to have a single configuration file, namely, config.h. From my (naive autoconf user's) perspective, there is no difference between PACKAGE_VERSION and DATADIR. With kind regards, Baurzhan.
SYSCONFDIR: config.h vs. AM_CFLAGS
Hello, I'm using SYSCONFDIR in one of my C source files. Currently I pass it through the following definition: AM_CFLAGS = ... -DSYSCONFDIR=\@[EMAIL PROTECTED] This is cluttering the gcc command line, so I want to define it in config.h. However, I can't figure out how to use it, since autoheader says that acconfig.h is deprecated, and both config.h.in and config.h are auto-generated. Is defining everything on the command line really the best and intended way to do that? Thanks in advance, Baurzhan.
Re: SYSCONFDIR: config.h vs. AM_CFLAGS
[EMAIL PROTECTED] wrote: I'm using SYSCONFDIR in one of my C source files. Currently I pass it through the following definition: AM_CFLAGS = ... -DSYSCONFDIR=\@[EMAIL PROTECTED] This is cluttering the gcc command line, so I want to define it in config.h. Isn't config.h created at configure time? AFAIK directory installation variables should only be defined at make time. See ``info Autoconf Installation Directory Variables''. Maybe you could use instead a dedicated header, created through the Makefile. See ``info Autoconf Defining Directories''.[2] -- Leonardo Boiko signature.asc Description: OpenPGP digital signature
Re: AM_CFLAGS in the project root?
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?
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: automake-1.7.7 and AM_CFLAGS/CFLAGS
Harlan == Harlan Stenn [EMAIL PROTECTED] writes: Harlan I'm trying hard to keep the warnings, as I want the Harlan developers to write cleaner code... Ah, sorry. Then it's probably better not to append anything to CFLAGS from ./configure. Put all your extra flags in SOFTW_CFLAGS or KMOD_CFLAGS, AC_SUBST these, and define `AM_CFLAGS = $(SOFTW_CFLAGS)' or `AM_CFLAGS = $(KMOD_CFLAGS)' in each Makefile. Note that if you use per-target _CFLAGS, you will also have to append $(AM_CFLAGS) to each such variables. Probably only of these translation can be automated so you don't hand-edit your 100+ Makefiles. -- Alexandre Duret-Lutz
automake-1.7.7 and AM_CFLAGS/CFLAGS
I have an automake/autoconf package that builds normal software and also kernel modules. configure builds a default set of CFLAGS that gets used to build general software. The problem is that the Makefile.am for any kernel code needs to use different CFLAGS, and when automake sees this we get the: `CFLAGS' is a user variable, you should not override it; use `AM_CFLAGS' instead. This application has thousands of Makefile.am's - any ideas on a good way to fix this problem? H
Re: automake-1.7.7 and AM_CFLAGS/CFLAGS
Harlan == Harlan Stenn [EMAIL PROTECTED] writes: [...] Harlan The problem is that the Makefile.am for any kernel code needs to use Harlan different CFLAGS, and when automake sees this we get the: Harlan `CFLAGS' is a user variable, you should not override it; Harlan use `AM_CFLAGS' instead. Harlan This application has thousands of Makefile.am's - any Harlan ideas on a good way to fix this problem? I don't know if any of these will be good for you, but here are three ideas: put `AUTOMAKE_OPTIONS = -Wno-gnu' in all the affected Makefile.am, or a use global `AM_INIT_AUTOMAKE([-Wno-gnu])', or try to gather all kernel modules inside a subpackage with its own configure and different CFLAGS. -- Alexandre Duret-Lutz
Re: automake-1.7.7 and AM_CFLAGS/CFLAGS
Thanks, if it comes down to it I'll put AUTOMAKE_OPTIONS=-Wno-gnu in the affected Makefile.am's. I'm trying hard to keep the warnings, as I want the developers to write cleaner code... H
Re: Difference between AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS
On Tue, 2002-09-10 at 01:06, Paul Smith wrote: Steve gave you the advantage: so you can run them individually. There are many compilers that won't accept linker flags (libraries, etc.) on a command line meant to compile a file (but not link it). The reason for having a separate CFLAGS and CPPFLAGS is even stronger: often you want to just run the C preprocessor (or a tool that takes the same arguments as the C preprocessor) either for debugging, or running tools like lint, or instrumenting your code with special debugging capabilities, etc. In this case you need to be able to run the preprocessor and be sure you're getting all the same arguments as when you compile the code into an object file. Thanks for the reply. I will work on the project separating the the flags into the three variables. Stephen
Difference between AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS
I am just posting this to make sure I understand the difference between these: AM_CFLAGS - compile time flags AM_CPPFLAGS - preprocessor flags (e.g. -I, -D) AM_LDFLAGS - linker flags (e.g. -L) I am working on a project that is updating its Makefile.am files. I see a variety of flags in one variable like CFLAGS contains -I and -F flags for example. I was wondering what is the advantage of doing this with automake variables? Stephen
Re: Difference between AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS
On Mon, 2002-09-09 at 23:11, Steve M. Robbins wrote: On Mon, Sep 09, 2002 at 10:33:40PM -0500, Stephen Torri wrote: I am just posting this to make sure I understand the difference between these: AM_CFLAGS - compile time flags AM_CPPFLAGS - preprocessor flags (e.g. -I, -D) AM_LDFLAGS - linker flags (e.g. -L) Yes. I am working on a project that is updating its Makefile.am files. I see a variety of flags in one variable like CFLAGS contains -I and -F flags for example. I was wondering what is the advantage of doing this with automake variables? Are you asking what is the advantage of separating them as automake does? I guess the advantage is that automake uses, e.g. LDFLAGS for linking lines where generic CFLAGS (-O, -g) might upset the linker. Yes. What is the advantage of separating them? Stephen
Re: Difference between AM_CFLAGS, AM_CPPFLAGS, and AM_LDFLAGS
%% Stephen Torri [EMAIL PROTECTED] writes: st On Mon, 2002-09-09 at 23:11, Steve M. Robbins wrote: On Mon, Sep 09, 2002 at 10:33:40PM -0500, Stephen Torri wrote: AM_CFLAGS - compile time flags AM_CPPFLAGS - preprocessor flags (e.g. -I, -D) AM_LDFLAGS - linker flags (e.g. -L) I am working on a project that is updating its Makefile.am files. I see a variety of flags in one variable like CFLAGS contains -I and -F flags for example. I was wondering what is the advantage of doing this with automake variables? Are you asking what is the advantage of separating them as automake does? I guess the advantage is that automake uses, e.g. LDFLAGS for linking lines where generic CFLAGS (-O, -g) might upset the linker. st Yes. What is the advantage of separating them? Steve gave you the advantage: so you can run them individually. There are many compilers that won't accept linker flags (libraries, etc.) on a command line meant to compile a file (but not link it). The reason for having a separate CFLAGS and CPPFLAGS is even stronger: often you want to just run the C preprocessor (or a tool that takes the same arguments as the C preprocessor) either for debugging, or running tools like lint, or instrumenting your code with special debugging capabilities, etc. In this case you need to be able to run the preprocessor and be sure you're getting all the same arguments as when you compile the code into an object file. -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT--HA Software Mthds Tools Please remain calm...I may be mad, but I am a professional. --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them.
Re: AM_CFLAGS and sub/foo.c
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
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
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
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
"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
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
"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
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
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
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
"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
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
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
