[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AM_C*FLAGS and C*FLAGS
From: |
Ralf Corsepius |
Subject: |
Re: AM_C*FLAGS and C*FLAGS |
Date: |
Mon, 26 Jun 2006 10:15:37 +0200 |
On Mon, 2006-06-26 at 04:34 +0000, Harlan Stenn wrote:
> We are told that we should not use CPPFLAGS or CFLAGS in a Makefile.am,
> as they are for users.
That's only partially true.
More precisely: You should not override user-supplied CPPFLAGS, CFLAGS,
CXXFLAGS, LIBS etc.
Appending something to these vars would be OK, provided the
user-provided settings "always win".
> The trick is that if we use a configure.ac file to help decide what
> flags may be needed, >inside< this configure script we need to use
> CFLAGS and CPPFLAGS to effect the running of configure.
Depends on what you add to *FLAGS.
One standard approach would be to use *FLAGS as package-global FLAGS and
AM_*FLAGS as per-Makefile.am FLAGS, i.e. not to AC_SUBST(AM_*FLAGS)
inside of a configure.ac, but set up AM_*FLAGS inside of each
Makefile.am anew from other AC_SUBST'ed vars to provide more
fine-grained control over FLAGS.
How to handle this inside of a configure.ac is up to you and depends on
your package's demands.
The big pitfall inside of all this trying to setup optimization flags.
In general, these should not be under a configure.ac's control, but
under user control. My recommendation is not trying to setup
optimization flags.
Ralf