* bug#11485: In configure.in, gl_EARLY is too early?
@ 2012-05-16 2:34 Glenn Morris
2012-05-16 8:00 ` Andreas Schwab
2012-05-16 9:10 ` Paul Eggert
0 siblings, 2 replies; 5+ messages in thread
From: Glenn Morris @ 2012-05-16 2:34 UTC (permalink / raw)
To: 11485
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11485: In configure.in, gl_EARLY is too early?
2012-05-16 2:34 bug#11485: In configure.in, gl_EARLY is too early? Glenn Morris
@ 2012-05-16 8:00 ` Andreas Schwab
2012-05-16 16:21 ` Glenn Morris
2012-05-16 9:10 ` Paul Eggert
1 sibling, 1 reply; 5+ messages in thread
From: Andreas Schwab @ 2012-05-16 8:00 UTC (permalink / raw)
To: Glenn Morris; +Cc: 11485
Isn't the CPP dance obsolete now that we no longer preprocess makefiles?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#11485: In configure.in, gl_EARLY is too early?
2012-05-16 2:34 bug#11485: In configure.in, gl_EARLY is too early? Glenn Morris
2012-05-16 8:00 ` Andreas Schwab
@ 2012-05-16 9:10 ` Paul Eggert
1 sibling, 0 replies; 5+ messages in thread
From: Paul Eggert @ 2012-05-16 9:10 UTC (permalink / raw)
To: 11485
Andreas is right that CPP is no longer needed.
I have removed that stuff from the trunk in bzr 108252.
In the trunk, I also moved gl_EARLY to the place where
Glenn suggested, as that makes sense.
If gl_EARLY overrides the other CPP stuff
in emacs-24, that shouldn't harm emacs-24, since we don't
care what CPP is.
However, if gl_EARLY overrides the other CC stuff
that might be a problem. This would affect two platforms:
Apple Darwin / Maco OS X (where emacs-24 currently
adds -I/sw/include and -L/sw/lib) and Iris 4D
(where it adds -D_LANGUAGE_C). So it might make
sense in the emacs-24 trunk to move gl_EARLY as Glenn
suggests, if only because of these two issues.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-05-18 16:34 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-05-16 2:34 bug#11485: In configure.in, gl_EARLY is too early? Glenn Morris
2012-05-16 8:00 ` Andreas Schwab
2012-05-16 16:21 ` Glenn Morris
2012-05-18 16:34 ` Glenn Morris
2012-05-16 9:10 ` Paul Eggert
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).