Setting up CDT to work on SpiderMonkey

  • Revision slug: SpiderMonkey/Setting_up_CDT_to_work_on_SpiderMonkey
  • Revision title: Setting up CDT to work on SpiderMonkey
  • Revision id: 11297
  • Created:
  • Creator: tschneidereit
  • Is current revision? No
  • Comment Removed workarounds for bugs in CDT that have since been fixed; 63 words added, 111 words removed

Revision Content

The version of Eclipse’s CDT that’s will be released with the next major release of Eclipse, codenamed “Juno”, has some pretty decent features that make it an attractive environment to work in.

There's a guide for setting up CDT to work with the Mozilla codebase, but it's a bit outdated and doesn’t cover setting things up for just SpiderMonkey instead of the whole Mozilla codebase. Hence, here’s a short-ish guide for doing just that:

Step 1 - Preparing a SpiderMonkey build

For CDT to index all code, SpiderMonkey has to be built with debug information. The full process of and requisites for doing so are described here. Please follow those instructions up until the point of invoking configure.

I prefer building with clang, so my modified build commands look like this:

mkdir _DBG.OBJ
cd _DBG.OBJ
CC='clang -Qunused-arguments -fcolor-diagnostics' CXX='clang++ -Qunused-arguments -fcolor-diagnostics' \
    ../configure --enable-debug --disable-optimize --enable-debug-symbols
Note: Due to a bug in CDT, it’s currently not possible (or at least not straight-forward) to build with ccache. See Step 4 below for a workaround.

Step 2 - Installing Eclipse and setting up the project

The following run-down is a condensed and updated version of what’s explained in much more detail for the entire Mozilla codebase. Luckily, improvements in CDT have reduced the basic process to a manageable 9 steps:

  1. Download and extract “Eclipse IDE for C/C++ Developers” from the Eclipse Developer builds
  2. Start Eclipse and create a workspace somewhere
  3. Select “Install New Software…” from the “Help” menu
  4. Click the “Add…” button in the upper right to add a repository and enter "http://download.eclipse.org/<wbr>tools/cdt/builds/juno/nightly</wbr>" as the location. (Use “Juno Nightly” or something similar as the name.)
  5. Select “C/C++ Development Tools” from “CDT Main Features” and whatever you want from “CDT Optional Features” and click “Next” and agree to licenses and installing unsigned packages and all that jazz until you’re prompted to restart
  6. Restart Eclipse
  7. Back in Eclipse, select “New > Makefile Project with Existing Code” from the “File” menu
  8. Give the project a name you like (“SpiderMonkey” has a nice ring to it) and use the “Browser…” button to select your checkout’s js/src folder for the “Existing Code Location”
  9. Choose the correct toolchain for your platform (i.e. MacOSX GCC on Mac) and click “Finish”

<wbr>

<wbr/>

<wbr>

<wbr> </wbr>

<wbr><wbr>

At this point, the indexer starts running and already produces a pretty decent index of much of SpiderMonkey. Still, there are a quite a few things that CDT doesn’t pick up yet: For everything to be indexed, CDT has to be aware of the project’s build details.

Step 3 - Index all the code

To let CDT know about the build, it has to invoke make itself (or, as is done in the guide for the whole Mozilla codebase on MDN, read a log of the build). This can be setup in another set of decently simple steps:

  1. Open the project’s properties by selecting its root and clicking “Properties” in the “File” menu and select “C/C++ Build”
  2. Under “Builder Settings”, deactivate “Use default build command”
  3. Instead, change “Build command” to read make -w (this is required because CDT needs detailed information about which directories make operates on, which using -w causes make to provide)
  4. Change the “Build location” to the build directory configured in step 1. For me, that means changing “Build directory” to read ${workspace_loc:/SpiderMonkey/_DBG.OBJ}
  5. Under “Behavior”, make sure that “Enable parallel build” is deactivated, as CDT’s indexer will freak out otherwise
  6. Remove “all” from “Build (Incremental build)”
  7. Deactivate “Clean” so that your builds don’t take ages
  8. Start the build by selecting “Build All” from the “Project” menu
  9. Start the indexer by selecting “Index > Rebuild” from the project’s context menu

And that’s pretty much it: Large parts of SpiderMonkey should now be indexed. Unfortunately, there are also large parts that aren’t properly indexed, leading to errors and warnings being shown for perfectly valid code, but I find that the parts that do work do so nicely enough to make it totally worth it.

That leaves us with only one thing to do:

Step 4 - Speeding it up

As mentioned above, CDT doesn’t like ccache for some reason. Until that bug is fixed, a somewhat simple workaround is to hide the usage of ccache by wrapping it with shell scripts for gcc/g++ and clang/clang++, respectively. I use clang, so I put two scripts into /usr/local/bin/:

cclang:

#!/bin/bash
/usr/local/bin/ccache /usr/local/bin/clang $@

cclang++:

#!/bin/bash
/usr/local/bin/ccache /usr/local/bin/clang++ $@

After a quick chmod u+x /usr/local/bin/cclang*, use the following configure command to start working with ccache after all:

CC='cclang -Qunused-arguments -fcolor-diagnostics' CXX='cclang++ -Qunused-arguments -fcolor-diagnostics' \
    ../configure --enable-debug --disable-optimize --enable-debug-symbols

See also

 

 

</wbr></wbr></wbr></wbr>

Revision Source

<p>The version of <a class="external" href="http://wiki.eclipse.org/CDT/">Eclipse’s CDT</a> that’s will be released with the <a href="/" title="">next major release of Eclipse, codenamed “Juno”</a>, has <a class="external" href="http://wiki.eclipse.org/CDT/User/NewIn81">some pretty decent features</a> that make it an attractive environment to work in.</p>
<p>There's a <a href="/en/Eclipse_CDT" title="en/Eclipse_CDT">guide for setting up CDT to work with the Mozilla codebase</a>, but it's a bit outdated and doesn’t cover setting things up for just SpiderMonkey instead of the whole Mozilla codebase. Hence, here’s a short-ish guide for doing just that:</p>
<h2>Step 1 - Preparing a SpiderMonkey build</h2>
<p>For CDT to index all code, SpiderMonkey has to be built with debug information. The full process of and requisites for doing so are <a href="/En/SpiderMonkey/Build_Documentation#Advanced_build" title="En/SpiderMonkey/Build_Documentation#Advanced_build">described here</a>. Please follow those instructions up until the point of invoking <code>configure</code>.</p>
<p>I prefer building with clang, so my modified build commands look like this:</p>
<pre><code><span class="line">mkdir _DBG.OBJ
</span><span class="line">cd _DBG.OBJ
</span><span class="line">CC='clang -Qunused-arguments -fcolor-diagnostics' CXX='clang++ -Qunused-arguments -fcolor-diagnostics' \
    ../configure --enable-debug --disable-optimize --enable-debug-symbols</span></code>
</pre>
<div class="note"><strong>Note:</strong> Due to <a class="link-https" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=378984">a bug in CDT</a>, it’s currently not possible (or at least not straight-forward) to build with ccache. See Step 4 below for a workaround.</div>
<h2>Step 2 - Installing Eclipse and setting up the project</h2>
<p>The following run-down is a condensed and updated version of what’s explained in much more detail <a href="/en/Eclipse_CDT" title="en/Eclipse_CDT">for the entire Mozilla codebase</a>. Luckily, improvements in CDT have reduced the basic process to a manageable 9 steps:</p>
<ol> <li>Download and extract “Eclipse IDE for C/C++ Developers” from the <a class="external" href="http://www.eclipse.org/downloads/index-developer.php">Eclipse Developer builds</a></li> <li>Start Eclipse and create a workspace somewhere</li> <li>Select “Install New Software…” from the “Help” menu</li> <li>Click the “Add…” button in the upper right to add a repository and enter "<a class=" external" href="http://download.eclipse.org/tools/cdt/builds/juno/nightly" target="_blank">http://download.eclipse.org/&lt;wbr&gt;tools/cdt/builds/juno/nightly&lt;/wbr&gt;</a>" as the location. (Use “Juno Nightly” or something similar as the name.)</li> <li>Select “C/C++ Development Tools” from “CDT Main Features” and whatever you want from “CDT Optional Features” and click “Next” and agree to licenses and installing unsigned packages and all that jazz until you’re prompted to restart</li> <li>Restart Eclipse</li> <li>Back in Eclipse, select “New &gt; Makefile Project with Existing Code” from the “File” menu</li> <li>Give the project a name you like (“SpiderMonkey” has a nice ring to it) and use the “Browser…” button to select your checkout’s <code>js/src</code> folder for the “Existing Code Location”</li> <li>Choose the correct toolchain for your platform (i.e. MacOSX GCC on Mac) and click “Finish”</li>
</ol>
<p>&lt;wbr&gt; </p><p>&lt;wbr/&gt;</p> &lt;wbr&gt; <p>&lt;wbr&gt; &lt;/wbr&gt;</p> &lt;wbr&gt;&lt;wbr&gt; <p>At this point, the indexer starts running and already produces a pretty decent index of much of SpiderMonkey. Still, there are a quite a few things that CDT doesn’t pick up yet: For everything to be indexed, CDT has to be aware of the project’s build details.</p> <h2>Step 3 - Index all the code</h2> <p>To let CDT know about the build, it has to invoke make itself (or, as is done in the guide for the whole Mozilla codebase on MDN, read a log of the build). This can be setup in another set of decently simple steps:</p> <ol> <li>Open the project’s properties by selecting its root and clicking “Properties” in the “File” menu and select “C/C++ Build”</li> <li>Under “Builder Settings”, deactivate “Use default build command”</li> <li>Instead, change “Build command” to read <code>make -w</code> (this is required because CDT needs detailed information about which directories <code>make</code> operates on, which using <code>-w</code> causes <code>make</code> to provide)</li> <li>Change the “Build location” to the build directory configured in step 1. For me, that means changing “Build directory” to read <code>${workspace_loc:/SpiderMonkey/_DBG.OBJ}</code></li> <li>Under “Behavior”, make sure that “Enable parallel build” is <em>deactivated</em>, as CDT’s indexer will freak out otherwise</li> <li>Remove “all” from “Build (Incremental build)”</li> <li>Deactivate “Clean” so that your builds don’t take ages</li> <li>Start the build by selecting “Build All” from the “Project” menu</li> <li>Start the indexer by selecting “Index &gt; Rebuild” from the project’s context menu</li> </ol> <p>And that’s pretty much it: Large parts of SpiderMonkey should now be indexed. Unfortunately, there are also large parts that aren’t properly indexed, leading to errors and warnings being shown for perfectly valid code, but I find that the parts that <em>do</em> work do so nicely enough to make it totally worth it.</p> <p>That leaves us with only one thing to do:</p> <h2>Step 4 - Speeding it up</h2> <p>As mentioned above, CDT doesn’t like ccache for some reason. Until <a class="link-https" href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=378984">that bug</a> is fixed, a somewhat simple workaround is to hide the usage of ccache by wrapping it with shell scripts for <code>gcc</code>/<code>g++</code> and <code>clang</code>/<code>clang++</code>, respectively. I use clang, so I put two scripts into <code>/usr/local/bin/</code>:</p> <p>cclang:</p> <pre><code><span class="line">#!/bin/bash
</span><span class="line">/usr/local/bin/ccache /usr/local/bin/clang $@</span></code>
</pre> <p>cclang++:</p> <pre><code><span class="line">#!/bin/bash
</span><span class="line">/usr/local/bin/ccache /usr/local/bin/clang++ $@</span></code>
</pre> <p>After a quick <code>chmod u+x /usr/local/bin/cclang*</code>, use the following configure command to start working with ccache after all:</p> <pre><code><span class="line">CC='cclang -Qunused-arguments -fcolor-diagnostics' CXX='cclang++ -Qunused-arguments -fcolor-diagnostics' \
    ../configure --enable-debug --disable-optimize --enable-debug-symbols</span></code>
</pre> <h2>See also</h2> <ul> <li><a href="/En/SpiderMonkey/Build_Documentation" title="en/SpiderMonkey/Build_Documentation">SpiderMonkey Build Documentation</a></li> </ul> <p> </p> <p> </p> &lt;/wbr&gt;&lt;/wbr&gt;&lt;/wbr&gt;&lt;/wbr&gt;<p></p>
Revert to this revision