On Mon, 2006-06-26 at 04:34 +, 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
On Mon, 2006-06-26 at 04:34 +, 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
Hi Alexandre et al.,
In November/December 2003, we started thinking about how to extend automake
so that po/Makefile.in.in can be replaced with a po/Makefile.am or entirely
integrated into the main Makefile.am.
On 2003-11-11 I explained the details of existing PO file support.
Hello,
On Sat, Jun 24, 2006 at 02:24:09PM +0200, Tom Bachmann wrote:
a way to do this but $(eval include bar.mk),
Automake is not preprocessing the whole file, so there are easier
ways to fool it:
NULL =
$(NULL)include hoo
or
include = include
$(include) hoo
Have a nice day,
Stepan
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.
Not really. Just AC_SUBST a variable in the AM_CFLAGS or AM_CPPFLAGS
directive. E.g., when I write an
We're happy to announce the release of Autoconf 2.60.
Please grab it from one of the gnu.org mirror sites.
The important changes since 2.59 are listed below. Two of these
changes require special attention:
* Some directory variables have been added, and others adjusted to
changes in the GNU
