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 pas
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
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\""
>>
(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 ab
a 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 sys
ave 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_
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
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
On 10/12/2012 01:20, Jeffrey Walton wrote:
> 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?
I haven't hit that
On Sun, Dec 9, 2012 at 7:14 PM, Diego Elio Pettenò
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-
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 writin
owhere 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. Th
owhere 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. Th
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 defau
On 12/09/2012 05:32 PM, NightStrike wrote:
> I was looking in the manual to see what the default definition of
> AM_CFLAGS was. It's gone.
>
Can you report the definition you used to see? I think your repost is
spurious, because "git log -G AM_CFLAGS" tells me that, in t
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 i
() 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 p
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
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 t
() 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.
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 t
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 yo
* 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 targ
e 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 -an
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
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 the
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 t
Hi
Norbert Sendetzky wrote:
> Hi all
>
> I've tried to set the C flags for my package globally and used AM_CLFAGS for
> this. Unfortunately AM_CLFAGS is only honored if it is defined in the same
> Makefile.am.
>
> AM_CFLAGS = -Wall -ansi -pedantic
> pkglib_LTL
Hi all
I've tried to set the C flags for my package globally and used AM_CLFAGS for
this. Unfortunately AM_CLFAGS is only honored if it is defined in the same
Makefile.am.
AM_CFLAGS = -Wall -ansi -pedantic
pkglib_LTLIBRARIES = libmysqlbackend.la
libmysqlbackend_la_SOURCES = mysqlback
Hi all
I've tried to set the C flags for my package globally and used AM_CLFAGS for
this. Unfortunately AM_CLFAGS is only honored if it is defined in the same
Makefile.am.
AM_CFLAGS = -Wall -ansi -pedantic
pkglib_LTLIBRARIES = libmysqlbackend.la
libmysqlbackend_la_SOURCES = mysqlback
gt; > > >
> > > > 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
> > > >
lation 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_C
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 compi
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
&
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
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 duri
[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 ha
[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 creat
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
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.
>>> "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
Hello,
I have a project with two subdirectories. I want to override standard
CFLAGS. I can do this by defining AM_CFLAGS in each subdirectory. This
works. However, I want to have it in one place. So I've tried to define
this variable in the root directory instead of subdirectories, but in
t 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 t
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
ou 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 `AUTO
utomake 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
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 CF
%% 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. -
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
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
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,
b/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 everyt
>>>>> "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
>>>>> "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
Stev
Hi,
I'm quite confused by the behaviour of CVS automake and AM_CFLAGS.
Given the following Makefile.am
bin_PROGRAMS = foo
foo_SOURCES = foo.c sub/foo2.c
it turns out that "foo.c" is compiled using $(COMPILE), and hence
includes AM_CFLAGS. However, "
>>>>> "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
> 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_a
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> ifdef([m4_pattern_allow],[m4_pattern_allow([AM_CFLAGS])])
Thanks.
Tom
fdef([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, redha
e> 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.
reversed :-(
I suppose automake should remove AM_CFLAGS et al from autoconf's
blacklist, then.
--
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@{l
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_".
>
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,
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
>>>>> "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.
>> H
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 thes
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?
Tom
67 matches
Mail list logo
