bug-gnu-emacs
[Top][All Lists]
Advanced

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





reply via email to

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