* Various code inside and outside of JS uses JS_BYTES_PER_WORD, so I added it to js-config.h
* Existing code uses JS_BYTES_PER_DOUBLE, JS_BITS_PER_WORD_LOG2, and JS_ALIGN_OF_POINTER so I've added autoconf tests for those
r=crowder r=jimb
* Various code inside and outside of JS uses JS_BYTES_PER_WORD, so I added it to js-config.h
* Existing code uses JS_BYTES_PER_DOUBLE, JS_BITS_PER_WORD_LOG2, and JS_ALIGN_OF_POINTER so I've added autoconf tests for those
r=crowder r=jimb
Perform the appropriate configure-time tests, and hard-code the
answers for targets that don't support autoconf-style tests. Check
for the io.h header, and the setbuf and isatty library functions.
In js/src/xpconnect/shell/xpcshell.cpp, use configure-#defined
preprocessor symbols to decide what to #include and use. The
top-level configure script defines the preprocessor symbols used here.
In js/src/prmjtime.cpp, use them to select the appropriate method for
retrieving fine-grained time information for Windows and WinCE. The
js/src/configure script defines the preprocessor symbols used here.
(This should cover the issues addressed by patch.v2 in bug 461841,
except for the stdint issue.)
At configure time, check for <stdint.h>. If we don't have it, find
integer types of various sizes. On Windows, where we can't run
compilation tests in configure, hard-code definitions suggesting the
use of the built-in __intN types for the exact-size types, and
<stddef.h> for the pointer-sized types.
Use namespace-clean names for the preprocessor macros we define.
Since these types are used in the public JavaScript API, the configure
script needs to place the definitions it finds in js-config.h, the
installed configure-generated header, so it can be used by jsapi.h and
that gang.
New header js/src/jsstdint.h does what it takes to get definitions for
the exact-size and pointer-size integral types. It includes
<stdint.h> when available, uses the types found by configure.in to
define the {,u}int{8,16,32,64,ptr}_t types itself, or uses the __intN
types and the <stddef.h> header.
Remove now-unnecessary and possibly conflicting definitions of intN_t
types from js/src/nanojit/avmplus.h.
This should have no effect; the test there is in the midst of a
section titled, "Checks for header files", and doesn't belong there.
I've made the same change in both the top-level configure.in and
js/src/configure.in, just to keep things parallel.
This controls whether NJ_ARM_VFP is #defined in the SpiderMonkey
build. By default it is enabled.
Note that commenting out the hard-wired definition of NJ_ARM_VFP in
js/src/nanojit/NativeARM.h makes that line of the file match what's in
tamarin-redux, so hopefully there won't be conflicts with whatever
arrangement Adobe comes up with to control this.
"cross_compiling=yes" to the very end of the if block so that it
is not overridden by AC_PROG_CC and AC_PROG_CXX. Removed the Mac
OS X ppc<->x86 code in the "else" block. r=jim,ted.mielczarek.
Intel recommends against the use of -Os, and using it seems to produce
incorrect code in many recent versions of Intel's compilers.
js/src/Makefile.in tries to use -Os only with G++, but it tests
INTEL_CC, not INTEL_CXX --- even though almost all the sources are
C++. Check INTEL_CXX instead.
Here's the commit that added this:
1.1764 <benjamin@smedbergs.us> 2007-01-31 08:12
No bug: checking to see which tinderboxes don't have python available.
It seems unlikely that this echo was meant to stay in the configure script.
SpiderMonkey now has its own copy of some of the files from ./config
and ./build. Since there is a decent amount of churn in that area, I
don't want it to become a burden to make merges back and forth. This
patch adds a comment explaining the 'identical if present' policy, and
runs a script to verify that it's actually being observed.
Have js/src/configure create a header file, js-config.h, that records
configure-controlled options that affect the SpiderMonkey API, like
'--enable-threadsafe'. js-config.h is namespace-clean, so it can be
installed with jsapi.h.
This means that clients can configure SpiderMonkey however they like,
and then simply #include "jsapi.h" and have everything work; they
don't have to remember to match their own compiler -D flags with those
SpiderMonkey's configure script chose. For example, mozilla-config.h
needn't concern itself with JS_THREADSAFE.
It seems to me this could also be done by having js-config --cflags
print -D options. The approach taken here seems a bit more robust: if
you can find jsapi.h at all, then you know you're getting the right
settings.
