SpiderMonkey Build Documentation

  • Revision slug: SpiderMonkey/Build_Documentation
  • Revision title: SpiderMonkey Build Documentation
  • Revision id: 39160
  • Created:
  • Creator: Jorend
  • Is current revision? No
  • Comment /* Building a trunk version of JavaScript */ fix busted link

Revision Content

Build

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 not normally found in a Mozilla source tree.

Logging into the CVS servers

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

Building a trunk version of JavaScript

Once you've logged into the server, it's time to fetch the code from CVS. First, you need to <tt>cd</tt> into the root of your CVS tree, then you can 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.

Now you can build JavaScript by doing 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.

Building a branch version of JavaScript

If you want to experiment with a specific branch's version of JavaScript, you need to check out js/src from branch but check out editline and config 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>).

Then you can compile and run the shell as in the previous section.

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>, it runs 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="Build"> Build </h2>
<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 not normally found in a Mozilla source tree.</div>
<h3 name="Logging_into_the_CVS_servers">Logging into the CVS servers</h3>
<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>
<h3 name="Building_a_trunk_version_of_JavaScript">Building a trunk version of JavaScript</h3>
<p>Once you've logged into the server, it's time to fetch the code from CVS.  First, you need to <tt>cd</tt> into the root of your CVS tree, then you can enter the following command:
</p>
<pre>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><p>Now you can build JavaScript by doing the following two commands:
</p>
<pre>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>
<h3 name="Building_a_branch_version_of_JavaScript">Building a branch version of JavaScript</h3>
<p>If you want to experiment with a specific branch's version of JavaScript, you need to check out js/src from branch but check out editline and config 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><p>Then you can compile and run the shell as in the previous section.
</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>, it runs 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