This adds the following options to the `configure` program
--shared-v8 Link to a shared V8 DLL instead of static linking
--shared-v8-includes=SHARED_V8_INCLUDES
Directory containing V8 header files
--shared-v8-libpath=SHARED_V8_LIBPATH
A directory to search for the shared V8 DLL
--shared-cares Link to a shared C-Ares DLL instead of static linking
--shared-cares-includes=SHARED_CARES_INCLUDES
Directory containing C-Ares header files
--shared-cares-libpath=SHARED_CARES_LIBPATH
A directory to search for the shared C-Ares DLL
--shared-libev Link to a shared libev DLL instead of static linking
--shared-libev-includes=SHARED_LIBEV_INCLUDES
Directory containing libev header files
--shared-libev-libpath=SHARED_LIBEV_LIBPATH
A directory to search for the shared libev DLL
and removes --system.
- No more single line "node.js:176:9" errors
- No more strange output when error happens on first line due to
module wrapper function.
- A few tests to check these things
While VM::Integer::Value() offers an int64_t, V8::Integer::New() only
accepts an int32_t, truncating fs.Stat's size in BuildStatsObject().
I consider this a bug in V8, and we should move back to V8::Integer
when it gets a ctr that allows a int64_t. Until then, this work-around
should hold.
After getting some feedback from Mikeal Rogers and Tim Smart, it was decided
that evalcx should not try to do any fancy security stuff, and instead leave
that in the hands of the user. To comply more with spidermonkey, everything
is passed in, and objects are passed in by reference rather than being
cloned.
1. Move the context->Enter() call so that the global obj is available for writing.
2. On success, copy the modified global out to the sandbox object.
3. Don't copy functions in either direction. They have scope and closures, and make for craziness when trying to keep contexts separate.
4. Only do the ->ToObject->Clone() on objects, so that simple values stay simple.
5. Update the test so that it tests all this stuff.