[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Merging AC_PROG_CC and AC_PROG_CPP (was: autoconf-2.49f/CPPFLAGS)
From: |
Akim Demaille |
Subject: |
Merging AC_PROG_CC and AC_PROG_CPP (was: autoconf-2.49f/CPPFLAGS) |
Date: |
27 Apr 2001 12:53:22 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) |
| Hi,
| Given this (trivial) configure.in (minimized version of an actual
| configure.in):
|
| AC_INIT(hello.c)
| AM_INIT_AUTOMAKE(test,1,no)
| AC_PROG_CC
| AM_CONFIG_HEADER(config.h)
| AC_OUTPUT(Makefile)
|
| Using autoconf-2.49f and vanilla automake-1.4 results into this:
|
| # ./configure
| ..
| # make
| gcc -DHAVE_CONFIG_H -I. -I. -I. @CPPFLAGS@ -g -O2 -c hello.c
| gcc: @CPPFLAGS@: Datei oder Verzeichnis nicht gefunden
| make: *** [hello.o] Error 1
|
| The return of a "N'aucun ficher ou repertoire" / "No such file or
| directory" bug :)
Actually you meant
~/src/ace % ls ralf nostromo 12:46
ls: ralf: Aucun fichier ou répertoire de ce type
:)
Well, I'm quite bugged by this one. My problem is that I believe that
CPPFLAGS should not be AC_SUBST if AC_PROG_CPP was not run (i.e.,
macros should mind their own business). And currently AC_PROG_CC does
require AC_PROG_CPP but the converse is not true.
I _know_ that CPPFLAGS is used both by AC_PROG_CPP and AC_PROG_CC, so
it seems natural to document it in both or find a means to factor it
for both.
The fix I would like to apply would basically merge AC_PROG_CC and
AC_PROG_CPP together (likewise for the other languages). Does this
sound acceptable? It seems so much saner to me! Problem: this is
quite a small source-quake.
The Q'nD fix simply consists in adding an AC_SUBST of CPPFLAGS in
AC_INIT (which is what was done before).
- autoconf-2.49f/CPPFLAGS., Ralf Corsepius, 2001/04/25
- Merging AC_PROG_CC and AC_PROG_CPP (was: autoconf-2.49f/CPPFLAGS),
Akim Demaille <=