[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11485: In configure.in, gl_EARLY is too early?
From: |
Glenn Morris |
Subject: |
bug#11485: In configure.in, gl_EARLY is too early? |
Date: |
Tue, 15 May 2012 22:34:34 -0400 |
User-agent: |
Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) |
Package: emacs
Version: 24.0.96
Severity: important
configure.in contains the equivalent of this (abridged):
## On several platforms:
NON_GNU_CPP=<something>
# Initialize gnulib right after verifying that the C compiler works.
gl_EARLY
[...]
## If no CPP was specified, do something for Sun compilers.
if [...] && test x"$CPP" = x; then [do stuff]
[...]
## If NON_GNU_CPP was set and CPP was not, set CPP to NON_GNU_CPP.
if test "x$NON_GNU_CPP" != x && test x$GCC != xyes && test "x$CPP" = x
then
CPP="$NON_GNU_CPP"
fi
[...]
AC_PROG_CPP
The CPP tests all predate the use of Gnulib.
What gl_EARLY does is opaque, but by inspection of configure one thing
it ends up doing is calling AC_PROG_CPP and so setting $CPP much earlier
than the rest of configure.in expects.
IIUC, this will prevent all the pre-existing code related to changing
CPP from having any effect; because it all tests if CPP was already set,
and if so does nothing. It was expecting that CPP could only have been
set by the user at this stage; however now gnulib is going to make it
always be set.
Moving gl_EARLY later in configure.in (to just before the check for
-Wdeclaration-after-statement) would presumably restore the behaviour of
Emacs 23 and earlier.
However, all previous pretesting for Emacs 24 has used the other
behaviour, so I do not know if it is too late to change this.
It affects the less common platforms, which might not have seen much
testing.
One example is using a Sun compiler on Solaris.
The intent of configure was to add -Xs to the CPP options.
- bug#11485: In configure.in, gl_EARLY is too early?,
Glenn Morris <=