529936 - Eclipse / CDT project for Tamarin Redux

Status: RESOLVED FIXED

(Tamarin Graveyard :: Build Config, enhancement)

Description

[Simon Wilkinson]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_1; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9
Build Identifier: 

This patch comprises an Eclipse (Galileo) / CDT (6.0) project for Tamarin.

The configurations in this initial version cover 32-bit builds for Mac OS with the GCC 4.0 toolchain (installed with Xcode 3.2).
Linux/GCC, Windows/MinGW and Windows/cl.exe configuration are still under test, but can eventually reside in the same project.


Preparing your workspace
=====================================
As Eclipse is very inflexible as to how it presents the logical structure of your source tree, in this project, source folders are specified as relative workspace-linked resources. This gives an extra layer of indirection to work with.

- Open Eclipse preferences.
- Goto General >> Workspace >> Linked Resources
- Ensure 'Enable linked resources' is checked
- Add variable 'TAMARIN_ROOT'. It's value should be the full path to your top-level tamarin-redux directory


Preparing your perspective
=====================================
- Open the C/C++ perspective
- Open the 'C/C++ Projects' view (Window >> Show View >> C/C++ Projects)
- Add view filter 'Non-C Elements' (In the top-right of the 'C/C++ Projects' view, click the down-arrow, click 'Filters...', check 'Non-C elements')
- Increase the threshold for 'editor scalability mode' to 20000 lines. As some Tamarin source files have more than the Eclipse standard threshold of 5000, they do not appear as indexed. The threshold can be adjusted in Eclipse preferences >> C/C++ >> Editor >> Scalability.


Importing the project
=====================================
- File >> Import >> General >> Existing Projects into Workspace
- Click next
- The root directory should be the full path to your top-level tamarin-redux directory (i.e. the same as 'TAMARIN_ROOT')
- Ensure the 'avmshell' project is checked in the 'Projects' list
- Uncheck 'Copy projects into workspace'
- Click finish


Building
=====================================
4 build configurations are included for MacOS with the GCC 4.0 toolchain. These mirror those in the existing Xcode project:
Mac-32-Release
Mac-32-Debug
Mac-32-Release-Debugger
Mac-32-Debug-Debugger

Note: the build location will be TAMARIN_ROOT/BUILD_NAME/avmshell
Note: the C++ indexer has been setup to track the current build config, so the correct conditional compiles are highlighted in the editor


Run/Debug:
=====================================
For test purposes, a launch config (running the HelloWorld test from esc) has been included for each of the build configs. All are available from the Run menu.

Note: if you receive an error when try to run a newly imported project, try opening a file in the project first - Eclipse can sometimes get confused as to what the 'current project' actually is.


Reproducible: Always

Comment 1

[Simon Wilkinson]

Attachment: hg patch

Comment 2

[Simon Wilkinson]

It looks like a bug in Eclipse means that project-specific settings for the CDT Indexer do not work, so you have to set these manually/globally. What we want is to have the indexer track the currently selected build config (so the correct conditional compiles are highlighted in the editor). To enable this go to Eclipse preferences >> C/C++ >> Indexer, then select 'Use active build configuration' in the 'Build configuration for the indexer' section.

The above information has been added to the project's README, and is included in the new patch.

Also, for the moment, I've removed the mention of Linux and Windows build configs living in the same Eclipse project. Linux is nearly there, but Windows builds are so closely tied to MSVC that it need lots more work to convert to MinGW.

Comment 3

[Simon Wilkinson]

Attachment: Patch with revised README / workaround

Comment 4

[Edwin Smith]

Followed the instructions, worked perfectly.

Tried renaming Atom (in Atom.h).  Had to update the java heap to 1G, then it worked perfectly (126 files edited in about 20 seconds. nice!)

Comment 5

[Edwin Smith]

a few random notes, nothing actionable yet...

* Using the TAMARIN_ROOT workspace variable would seem to tie a person to using a single directory most of the time for work.  That's workable, but with mercurial its typical to have many clones of tamarin sitting around, which suggests the need for multiple tamarin projects in the workspace all at once.  i haven't tried this yet but it's something that would be nice if its feasiable.

* I tried turning on parallel builds, and it seemed to completely disable the internal builder's ability to do incremental error reporting.  So i turned it off... automatic builds are slow but since they're in the background, its tolerable.  Plus, building the old way (configure.py and make -j8) coexists fine with eclipse.

Comment 6

[Steven Johnson]

(In reply to comment #5)
> a single directory most of the time for work.  That's workable, but with
> mercurial its typical to have many clones of tamarin sitting around, which
> suggests the need for multiple tamarin projects in the workspace all at once. 

+1, at any time I have a halfdozen or more clones locally. Flexibility to switch between them is IMHO high priority for this to be a workable environment.

Comment 7

[Simon Wilkinson]

(In reply to comment #5)
> a few random notes, nothing actionable yet...
> 
> * Using the TAMARIN_ROOT workspace variable would seem to tie a person to using
> a single directory most of the time for work.  That's workable, but with
> mercurial its typical to have many clones of tamarin sitting around, which
> suggests the need for multiple tamarin projects in the workspace all at once. 
> i haven't tried this yet but it's something that would be nice if its
> feasiable.

TAMARIN_ROOT could be removed completely, but it would require that the logical
source-layout is exactly the same as the on-disk-layout. It's a choice between
what's most important - flexible folder structures or multiple projects per
workspace.

What we really want is something like VisualStudio's project view, where you
can have a logical source-tree layout which is completely separate from the
on-disk layout. Not possible in Eclipse though: You cannot specify
project-relative source locations, so you have to indirect via a named variable
(i.e. TAMARIN_ROOT) instead. Eclipse wont let you set these up per-project(!),
so they end up being at workspace scope.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=229633
and 
http://sergebeauchamp.blogspot.com/2008/09/improving-linked-resources-in-gandymede.html
It looks like this is all solved in Eclipse4, and is currently being backported
to 3.x.

> * I tried turning on parallel builds, and it seemed to completely disable the
> internal builder's ability to do incremental error reporting.  So i turned it
> off... automatic builds are slow but since they're in the background, its
> tolerable.  Plus, building the old way (configure.py and make -j8) coexists
> fine with eclipse.

Ah. I hadn't tested parallel builds. This has been filed already at:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=289048

Comment 8

[Simon Wilkinson]

I've removed TAMARIN_ROOT completely. You can now have multiple tamarin projects in one workspace.

The revised project files and readme are in the patch.

Comment 9

[Simon Wilkinson]

Attachment: Project files without TAMARIN_ROOT dependency

Comment 10

[Edwin Smith]

Comment on attachment 417131 [details] [diff] [review]
Project files without TAMARIN_ROOT dependency

Works fine for me.  I will push when the build system is back up, which should be Monday 12/21/09.

Comment 11

[Edwin Smith]

Comment on attachment 417131 [details] [diff] [review]
Project files without TAMARIN_ROOT dependency

pushed http://hg.mozilla.org/tamarin-redux/rev/ae7dda5c386a