Eclipse's CDT has some pretty decent features that make it an attractive environment to work in when you are interested in getting code hints, autocompletion, function, and field usage information and general IDE goodness for C/C++. There is a guide for setting up CDT to work with the Mozilla codebase, but it does not cover setting things up for just SpiderMonkey instead of the whole Mozilla codebase. Hence, here is 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.

The initial build was in clang, so the 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: If you want to use ccache, you can enable it by adding --with-ccache to the arguments list. Due to a bug in CDT, you have to make a small change to CDT's build configuration as explained in Step 3 below for that to work, though.

Step 2 - Installing Eclipse and setting up the project

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

  1. Download and extract "Eclipse IDE for C/C++ Developers" from the Eclipse downloads page.
  2. Start Eclipse and create a workspace somewhere.
  3. Select "New > Makefile Project with Existing Code" from the "File" menu.
  4. Give the project a name that 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".
  5. Choose the correct toolchain for your platform (i.e. MacOS X GCC on Mac) and click "Finish".

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 does not 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), which can be setup with these 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 the "Builder Settings" group tab, 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 do not take ages.
  8. If you want to use ccache: Select "C/C++ General", then "Preprocessor Include Patterns". Under the "Providers" group tab, select "CDT GCC Build Output Parser" and add the string |(ccache) to the end of the "Compiler command pattern" text input.
  9. Start the build by selecting "Build All" from the "Project" menu.
  10. Start the indexer by either:
    1. Selecting "Index > Rebuild" from the project's context menu located in the Project Explorer window, or
    2. Selecting "C/C++ Index > Rebuild" from the "Project" menu.

And that is pretty much it: large parts of SpiderMonkey should now be indexed. Unfortunately, there are also large parts that are not 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.

See also