From: Glenn Morris <rgm@gnu.org>
To: 11485@debbugs.gnu.org
Subject: bug#11485: In configure.in, gl_EARLY is too early?
Date: Tue, 15 May 2012 22:34:34 -0400 [thread overview]
Message-ID: <jvk40csvk5.fsf@fencepost.gnu.org> (raw)
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.
next reply other threads:[~2012-05-16 2:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-16 2:34 Glenn Morris [this message]
2012-05-16 8:00 ` bug#11485: In configure.in, gl_EARLY is too early? Andreas Schwab
2012-05-16 16:21 ` Glenn Morris
2012-05-18 16:34 ` Glenn Morris
2012-05-16 9:10 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jvk40csvk5.fsf@fencepost.gnu.org \
--to=rgm@gnu.org \
--cc=11485@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.