autoconf
[Top][All Lists]
Advanced

[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).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]