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