SpiderMonkey Build Documentation

  • Revision slug: SpiderMonkey/Build_Documentation
  • Revision title: SpiderMonkey Build Documentation
  • Revision id: 39163
  • Created:
  • Creator: Jorend
  • Is current revision? No
  • Comment Add instructions for building the latest official SpiderMonkey release (SM 1.7) from source

Revision Content

Get sources

SpiderMonkey is easy to build from source if you have the usual Mozilla build prerequisites installed. Before you begin, make sure you have right build tools for your computer: Linux, Windows, Mac, others.

Then, download and unzip the SpiderMonkey 1.7 source code:

mkdir mozilla
cd mozilla
wget http://ftp.mozilla.org/pub/mozilla.org/js/js-1.7.0.tar.gz
tar xzf js-1.7.0.tar.gz

SpiderMonkey 1.7 is the most recent official SpiderMonkey release. Alternatively, you can get the latest SpiderMonkey source code from CVS, as described below.

Getting the CVS trunk version of SpiderMonkey

Note: You will need to explicitly fetch the JavaScript shell sources even if you currently build another Mozilla project, as there are files specific to the shell that are not normally found in a Mozilla source tree.

Just like when you're fetching any other Mozilla project from CVS, you need to log into the CVS server first. To do this, <tt>cd</tt> into the base directory you'd like to check out the code into, then enter the following command at your command line:

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot login

When prompted, enter the password, <tt>anonymous</tt>.

Once you've logged in, <tt>cd</tt> into the root of your CVS tree and enter the following command:

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -l mozilla/js/src mozilla/js/src/config mozilla/js/src/editline mozilla/js/src/fdlibm

This checks out all the files needed in order to build the JavaScript shell.

Getting a branch version of SpiderMonkey

If you want to experiment with a specific branch's version of SpiderMonkey, you need to check out js/src from branch but check out <tt>editline</tt> and <tt>config</tt> from trunk:

cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -l -r BRANCH_NAME mozilla/js/src mozilla/js/src/fdlibm
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -l mozilla/js/src/config mozilla/js/src/editline

Change BRANCH_NAME to the name of the branch you want to check out. You can use a JavaScript branch name (e.g. <tt>JS_1_7_ALPHA_BRANCH</tt>) or a Mozilla branch name (e.g. <tt>MOZILLA_1_8_BRANCH</tt>).

Build

Once you have the source code, you can build SpiderMonkey by running the following two commands:

cd mozilla/js/src
make -f Makefile.ref

When compilation is complete, you should have an executable named <tt>js</tt> in a directory whose name depends on the system you're building on. For example, on Mac OS X, the executable is located at <tt>Darwin_DBG.OBJ/js</tt>.

At this point, you're ready to run and try out the shell.

By default, this makes a debug build. For an optimized build, add BUILD_OPT=1 to the make command line.

(On Windows, you might alternatively be able to use the nmake makefile, js.mak. But as of 2008-03-05, it does not work, and hasn't at least since JavaScript 1.7.)

Test

  • Run <tt>cd js/src; ./Linux_All_DBG.OBJ/js perfect.js</tt> (or using a similar directory with your platform's name) and check if appropriate output is printed.
  • Run the following command to start the test suite.
    cd ../tests; perl jsDriver.pl -L slow-n.tests -L spidermonkey-n.tests -k -e smdebug
    • Warning: The test suite could run up to 30-40 minutes and eats up a lot of CPU cycles.
  • If there are any failures, they will be recorded in a file, something like <tt>results-2007-08-23-010815-smdebug-failures.txt</tt>. Rename this file to <tt>spidermonkey-known-failures-n.tests</tt>.
    • As of 2007-08-23, there are around 175-200 failing tests.
    • If you compile SpiderMonkey with <tt>BUILD_OPT=1</tt>, you can use <tt>-e smopt</tt>. The tests run noticeably faster that way.
  • In subsequent test runs, you can add the option <tt>-L spidermonkey-known-failures-n.tests</tt> to the above test suite run command to ignore these failing tests. This way, you can make sure your code changes haven't broken anything which was previously working.

Revision Source

<h2 name="Get_sources">Get sources</h2>
<p><a href="en/SpiderMonkey">SpiderMonkey</a> is easy to build from source if you have the usual Mozilla build prerequisites installed.  Before you begin, make sure you have right build tools for your computer:  <a href="en/Linux_Build_Prerequisites">Linux</a>, <a href="en/Windows_Build_Prerequisites">Windows</a>, <a href="en/Mac_OS_X_Build_Prerequisites">Mac</a>, <a href="en/Build_Documentation">others</a>.
</p><p>Then, download and unzip the SpiderMonkey 1.7 source code:
</p>
<pre class="eval">mkdir mozilla
cd mozilla
wget http://ftp.mozilla.org/pub/mozilla.org/js/js-1.7.0.tar.gz
tar xzf js-1.7.0.tar.gz
</pre>
<p>SpiderMonkey 1.7 is the most recent official SpiderMonkey release.  Alternatively, you can get the latest SpiderMonkey source code from CVS, as described below.
</p>
<h3 name="Getting_the_CVS_trunk_version_of_SpiderMonkey">Getting the CVS trunk version of SpiderMonkey</h3>
<div class="note"><b>Note:</b> You will need to explicitly fetch the JavaScript shell sources even if you currently build another Mozilla project, as there are files specific to the shell that are not normally found in a Mozilla source tree.</div>
<p>Just like when you're fetching any other Mozilla project from CVS, you need to log into the CVS server first.  To do this, <tt>cd</tt> into the base directory you'd like to check out the code into, then enter the following command at your command line:
</p>
<pre class="eval">cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot login
</pre>
<p>When prompted, enter the password, <tt>anonymous</tt>.
</p><p>Once you've logged in, <tt>cd</tt> into the root of your CVS tree and enter the following command:
</p>
<pre class="eval">cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -l mozilla/js/src mozilla/js/src/config mozilla/js/src/editline mozilla/js/src/fdlibm
</pre>
<p>This checks out all the files needed in order to build the JavaScript shell.
</p>
<h3 name="Getting_a_branch_version_of_SpiderMonkey">Getting a branch version of SpiderMonkey</h3>
<p>If you want to experiment with a specific branch's version of SpiderMonkey, you need to check out js/src from branch but check out <tt>editline</tt> and <tt>config</tt> from trunk:
</p>
<pre class="eval">cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -l -r <var>BRANCH_NAME</var> mozilla/js/src mozilla/js/src/fdlibm
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot co -l mozilla/js/src/config mozilla/js/src/editline
</pre>
<p>Change <var>BRANCH_NAME</var> to the name of the branch you want to check out.  You can use a JavaScript branch name (e.g. <tt>JS_1_7_ALPHA_BRANCH</tt>) or a Mozilla branch name (e.g. <tt>MOZILLA_1_8_BRANCH</tt>).
</p>
<h2 name="Build">Build</h2>
<p>Once you have the source code, you can build SpiderMonkey by running the following two commands:
</p>
<pre class="eval">cd mozilla/js/src
make -f Makefile.ref
</pre>
<p>When compilation is complete, you should have an executable named <tt>js</tt> in a directory whose name depends on the system you're building on.  For example, on Mac OS X, the executable is located at <tt>Darwin_DBG.OBJ/js</tt>.
</p><p>At this point, you're ready to <a href="en/Introduction_to_the_JavaScript_shell">run and try out the shell</a>.
</p><p>By default, this makes a debug build.  For an optimized build, add <code>BUILD_OPT=1</code> to the <code>make</code> command line.
</p><p>(On Windows, you might alternatively be able to use the <code>nmake</code> makefile, <code>js.mak</code>.  But as of 2008-03-05, it does not work, and hasn't at least since JavaScript 1.7.)
</p>
<h2 name="Test">Test</h2>
<ul><li> Run <tt>cd js/src; ./Linux_All_DBG.OBJ/js perfect.js</tt> (or using a similar directory with your platform's name) and check if appropriate output is printed.
</li><li> Run the following command to start the test suite.
<dl><dd> <blockquote><pre>cd ../tests; perl jsDriver.pl -L slow-n.tests -L spidermonkey-n.tests -k -e smdebug</pre></blockquote> 
</dd></dl>
<ul><li> <i>Warning</i>: The test suite could run up to 30-40 minutes and eats up a lot of CPU cycles.
</li></ul>
</li><li> If there are any failures, they will be recorded in a file, something like <tt>results-2007-08-23-010815-smdebug-failures.txt</tt>. Rename this file to <tt>spidermonkey-known-failures-n.tests</tt>.
<ul><li> As of 2007-08-23, there are around 175-200 failing tests.
</li><li> If you compile SpiderMonkey with <tt>BUILD_OPT=1</tt>, you can use <tt>-e smopt</tt>.  The tests run noticeably faster that way.
</li></ul>
</li><li> In subsequent test runs, you can add the option <tt>-L spidermonkey-known-failures-n.tests</tt> to the above test suite run command to ignore these failing tests. This way, you can make sure your code changes haven't broken anything which was previously working.
</li></ul>
Revert to this revision