Using Eclipse to work with the LHCb software

Eclipse is a multi-platform development environment. Its extreme flexibility makes it possible to use it in a lot of environments, from the Java development to the Web development.

It is possible to use Eclipse also in LHCb, even if with still some rough edges that will be smoothed out if there are enough requests.


You need to be familiar with few LHCb developments concepts and tools:


Before proceeding, you need Eclipse.

You can chose between a custom installation and the shared one

  Pros Cons
Custom you can install the plugins you like most and keep them up-to-date you have to install it yourself and you will be probably limited to a single host
Shared pre-defined set of plugins updated more or less regularly can be run from lxplus, lxbuild or a desktop machine

This tutorial will make use of the shared installation I set up for LHCb for simplicity. Once you are familiar with Eclipse you can install your own copy (see EclipseConfiguration). I will highlight whenever something is specific to the LHCb installation with the symbol Warning, important.

We will also assume we are starting from an empty cmtuser directory.

First time


To start eclipse (requires LbScript >= v5r4), just log on lxplus5 an type

eclipse &

A dialog will ask you to select your workspace. It will propose you the standard cmtuser directory in your home directory Warning, important

snap 01.png
Workspace selection
If you use a different location for your $User_release_area, you have to change the workspace location to point to it.

The first time you create a workspace, Eclipse will show you a welcome page from which you can explore its features. This time we can close it with the button highlighted in the image. Close the Photran 6.0 (FORTRAN support) welcome page too.

snap 02.png
First time, welcome view

You should uncheck the entry Build Automatically from the menu Project. It is not needed in general, but we need to have it unchecked for the tutorial.

snap 03.png
Project / Build Automatically

From the Window menu select Preferences. Type "Python" in the filter box at the top of the left pane and select Interpreter - Python. For this tutorial you can click on the Auto Config button and accept the default. In some cases it will be necessary to use the actual Python interpreter (the one in the LCG externals), but for now the system one is enough. Click the OK button to store the changes to the configuration.

Now you that we made Eclipse create the configuration files in the workspace, you can go back to the command line prompt.

Create a User Project (setenv<Project> + getpack)


If you have followed the LHCbSoftwareTutorials, you know about setenv<Project> (AKA SetupProject --build-env) and getpack. Here we will use them to prepare a local project that we will work on using Eclipse.

In this example, we will work with the package Tutorial/EclipseTutorial using the project LHCb.

Check that the directory pointed to by $User_release_area is the one you used as workspace. If it is not the case, change the value of $User_release_area.

From the command prompt, prepare the local project with

SetupProject --build-env LHCb v31r8
getpack Tutorial/EclipseTutorial head

Let's go back to the Eclipse window (restart it if necessary).

From the menu File select Import, then General/Existing Projects into Workspace. In the dialog that appears, click on Browse... and select the directory of your project (LHCb_v31r8), then click the button Finish.

snap 04.png
Import Existing Project

Optionally (mainly if you want to work with many packages), you can go to the properties of the C/C++ Build group itself and in the Behaviour tab select the "parallel build" and the "optimal number of jobs".

snap 07.png
Parallel build configuration

Exit from the Properties dialog with the OK button.



Now we are ready to build: right-click again on the project and select Build Project (you can see the compilation going on in the Console tab at the bottom).

The package Tutorial/EclipseTutorial doesn't compile (on purpouse). You can see the error in the bottom pane in the tab Problems. Double-clicking on the problem will open the problematic file highlighting the line that caused the error. If you click on the two horizontal arrows at the top of the Project Explorer view (Link with Editor), the project explorer will show where the file you are currently editing is in the project hierarchy.

snap 08.png
Compile error

Correct the line (m_freq must be replaced with m_frequency), save the modified file (CTRL+s or File->Save or right-click in the editor) and build again.

Running the Tests


To run the tests of a package you need to call cmt TestPackage in the cmt directory of the package itself. You can tell Eclipse to do it by creating a custom "make target".

Right-click on the cmt directory of the package and, from the menu, select Make Targets -> Create.... Fill the dialog choosing the name TestPackage, uncheck Use builder settings, set the name of the builder to cmt and unckeck Run all project builders.

snap 09.png
Custom make target for the tests

Now select the Make Target tab in the right pane (may be hidden), look for the directory Tutorial/EclipseTutorial/cmt, which will contain the target TestPackage. Double-click to run it.

The summary of the tests is visible in the Console view in the bottom pane, but you can use the internal web browser to display the HTML test summary that you can find in the left pane: test_results/.../index.html. Right-click on the file and select Open With -> Web Browser.

snap 10.png
Result of the tests
(the HTML summary is available thaks to the environment variable GAUDI_QMTEST_HTML_OUTPUT)

When you run the tests from within an Eclipse project, the GaudiTestingInfrastructure creates launch configurations that can be use to execute the tests bypassing the QMTest wrapping (useful for debugging). You can access the configured launchers from the Run menu.



Eclipse has got a user-friendly graphical front-end to gdb.

First we need to compile in debug mode (using the Debug configuration we set up), so select Build Configurations -> Set Active -> Debug from the project contestual menu (right-click). Build and run the tests (to regenerate the launcher configurations).

Open the file CounterExampleAlg.cpp from the src directory of the package. Using the Outline view in the right pane, look for CounterExampleAlg::initialize and double-click in the gray bar on the left of the editor window at the level of the function definition to set a breakpoint, a small blue dot will appear.

snap 11.png
Setting a breakpoint

Unfortunately, there is a problem in the way the current version of Gaudi generates the launchers. To fix it select Debug Configurations... from the Run menu, go to the Debugger tab and close the dialog with the Close button.

From the Run menu select Debug History -> eclipsetutorial.simple_test. A dialog box will ask you if you want to switch to the Debug Perspective, tell it that you want and check the box to make it remember the decision.

The debugger will stop in the Python "main" function, and it will tell you that it doesn't have debug symbols for it. It's OK, let it continue by clicking the Resume (F8) button in the Debug view (top-left), which is a green triangle.

After some time, the debugger will stop at the breakpoint we defined before.

snap 12.png
Hitting a breakpoint

Now you can follow the what is happening in your code. BTW, did you notice the spell checking in the comments? wink

Other Topics

Running Eclipse on lxplus via VNC (for slow connections)

Most of the steps explained here are not Eclipse specific, so can be used to run any graphical session on lxplus from a remote (thin) client.

VNC is a standard protocol to allow interaction with a graphical session on a remote host. The advantages of VNC with respect to the plain X11 protocol are:

  • performance: VNC sessions are still usable over slow connections
  • portability: VNC server and clients are available for Linux, Mac and Windows

There is an interesting alternative to VNC that is called NoMachine NX, but it's not available on lxplus.

The basic prerequisite is to have a VNC viewer installed on the client machine (desktop, laptop, etc.). Several viewers are available for Linux (e.g. krdc for KDE, gtk-vnc for Gnome, xvncviewer...), Windows (TightVNC...) and Mac. If you do not want to install a viewer, it is enough to have a web browser with Java enabled.

First thing you have to log on lxplus.

Special care is needed the first time you start the vncserver:

  • it will ask you to set a password to access the server, it will be transmitted in clear text so choose a password only for this purpose; it is stored in a file in $HOME/.vnc so vncserver will not ask again
  • it will also create a file called $HOME/.vnc/xstartup which is needed to start the graphical session; the problem with it is that it uses twm as window manager, so probably you want to kill the server after the first start and modify that file replacing twm with icewm and restart

When you start the vncserver, you can specify the size of the virtual screen and the color depth. The best choice for the size is to use the same as the one of the client machine, while the color depth depends on the server memory, so you can safely use the maximum (24). For a screen of 1280x800 pixels, for example, use

vncserver -geometry 1280x800 -depth 24

To connect to the server from within the CERN network, you can start your client and pass the string that the server printed when started, e.g.

After giving the password to the client, you can (optionally) switch to full-screen mode (on xvncviewer you have to press F8 to access the menu) and start eclipse.

Once you have finished to use the session (you can decide to disconnect the client and reconnect later on if you need), it is better to kill the server with (e.g.):

vncserver -kill :2


When using VNC over an unsecure network or simply from outside the CERN network, you can use ssh to encrypt/tunnel the communication. Details about how to do it are easy to find on the web and some clients can even do it automatically.

More Topics (TO-DO list)

  • Interaction with Subversion
  • Advanced debugging
  • Templates
  • PyDev

-- MarcoClemencic - 10-Jan-2011

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatogv 01-starting.ogv r1 manage 6688.9 K 2010-09-15 - 10:22 MarcoClemencic  
Unknown file formatogv 02-new_project.ogv r2 r1 manage 7626.5 K 2011-01-10 - 20:06 MarcoClemencic  
Unknown file formatogv 03-building.ogv r1 manage 7427.2 K 2010-09-15 - 10:23 MarcoClemencic  
Unknown file formatogv 04-testing.ogv r1 manage 6283.4 K 2010-09-15 - 10:23 MarcoClemencic  
Unknown file formatogv 05-debugging.ogv r1 manage 22938.0 K 2010-09-15 - 10:23 MarcoClemencic  
Edit | Attach | Watch | Print version | History: r14 | r9 < r8 < r7 < r6 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r7 - 2011-01-10 - MarcoClemencic
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    LHCb All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback