Building SpiderMonkey 1.8.0 rc1 on Windows XP with Visual C++ 2008 / 9.0

Finding this note in SpiderMonkies documentation was a huge NO NO for me, because a dependency on Autoconf 2.13 is *worse* then a dependency on Autotools in general.

As I said I would, I investigated Windows/MSVC builds with SpiderMonkey before completing and utterly refusing to ever use the thing ^_^. This is a summery of my findings.

A lot of people are still using Visual C++ 7.1/2003.NET or 8.0/2005 versions, while I however use the Express Edition of Visual C++ 9.0/2008 for Windows builds, which generally means no pre-compiled libs binaries are available. That's ok, since I prefer to evaluate the buildability of a dependency before I commit to using it.... hehe. One perk of doing most of my coding under FreeBSD, no need to buy a Professional Edition of Visual Studio :-D. I think this post should apply to most versions of Microsoft's compiler, +/- differences in compiler flags.


The proper build requires MinGW, MSys, GNU Make, and a suitable copy of Visual C++.


MSys is required because of UNIX tools, such as uname, sed, and countless others are used by the build system; which also seems to depend on GNU Make.

Open the Visual Studio command prompt, or call  %VS90COMNTOOLS%\vsvars32.bat from your current cmd session (VS90 = 2008 fyi; adapt as needed for older/newer versions). Then execute a MSys RXVT terminal from that. You do that by running the msys.bat script in the MSys root with the -rxvt argument, example:

+> C:\DevFiles\MSYS\1.0\msys.bat -rxvt

which will close the cmd session and open RXVT.

Change over to the js/src directory of where you extracted SpideryMonkey to, and run make on the projects makefile:

bash $ pushd /C/DevFiles/Libraries/SpiderMonkey/1.8.0rc1/js/src/
bash $ make BUILD_OPT=1 -f Makefile.ref

The BUILD_OPT causes an optimised release build to be made, default seems to be debug builds; read the Makefiles and Wiki for details on that.


Now for an example app to test, to see if more then js.exe works!

bash $ cat > test.c

#include "jsapi.h"

/* The class of the global object. */
static JSClass global_class = {
    "global", JSCLASS_GLOBAL_FLAGS,
    JS_PropertyStub, JS_PropertyStub, JS_PropertyStub, JS_PropertyStub,
    JS_EnumerateStub, JS_ResolveStub, JS_ConvertStub, JS_FinalizeStub,
    JSCLASS_NO_OPTIONAL_MEMBERS
};

/* The error reporter callback. */
void reportError(JSContext *cx, const char *message, JSErrorReport *report)
{
    fprintf(stderr, "%s:%u:%s\n",
            report->filename ? report->filename : "",
            (unsigned int) report->lineno,
            message);
}

int main(int argc, const char *argv[])
{
    /* JS variables. */
    JSRuntime *rt;
    JSContext *cx;
    JSObject  *global;

    /* Create a JS runtime. */
    rt = JS_NewRuntime(8L * 1024L * 1024L);
    if (rt == NULL)
        return 1;

    /* Create a context. */
    cx = JS_NewContext(rt, 8192);
    if (cx == NULL)
        return 1;
    JS_SetOptions(cx, JSOPTION_VAROBJFIX);
    JS_SetVersion(cx, JSVERSION_LATEST);
    JS_SetErrorReporter(cx, reportError);

    /* Create the global object. */
    global = JS_NewObject(cx, &global_class, NULL, NULL);
    if (global == NULL)
        return 1;

    /* Populate the global object with the standard globals,
       like Object and Array. */
    if (!JS_InitStandardClasses(cx, global))
        return 1;


    /* Your application code here. This may include JSAPI calls
       to create your own custom JS objects and run scripts. */

    /* Cleanup. */
    JS_DestroyContext(cx);
    JS_DestroyRuntime(rt);
    JS_ShutDown();
    return 0;
}


bash $ $ cl -nologo -DXP_WIN  -I.. -MD -Fetest test.c js32.lib
bash $ ./test.exe

footnote: that test.c is just the minimal app example from the user guide, here. Also note that using /dos style switches with cl under bash/rxvt, doesn't seem to work (it's converted to file names).



I'll need to do some further testing but everything appears to be working fine.