On systems that don't have <stdint.h> (i.e., Microsoft, which is
tragically underfunded and cannot spare the resources necessary to
provide and support this header: http://tinyurl.com/absoh8),
SpiderMonkey header files should not introduce definitions for these
types, as doing so may conflict with client code's attempts to provide
its own definitions for these types.
Instead, have jstypes.h define JS{Int,Uint}{8,16,32,64,Ptr} types
based on configure's results, and make jsstdint.h into an uninstalled
header for use within SpiderMonkey that does whatever is necessary to
get definitions for the <stdint.h> types.
The changes to make the appropriate SpiderMonkey .cpp files #include
"jsstdint.h" explicitly are in a separate patch, for ease of review.
2009-03-18 11:38:15 -07:00
Benjamin Smedberg ext:(%2C%20Jason%20Orendorff%20%3Cjorendorff%40mozilla.com%3E)
* 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.
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.