ROOT is, for a start, a very silly name for a software package. The term was already overused even before the software development folks at CERN hijacked it. It’s like naming your kid

Sir. So they did not get off to a good start. For years the package suffered from a lousy manual, just like its predecessor PAW. This is now fixed as the reference manual and tutorials are actually rather good. Lastly, and most sadly, ROOT is not well designed from a software architecture point of view. It is a ragtag collection of classes with functionality distributed between them in a manner that is counterintuitive and confusing. External variables, a programming paradigm that is thankfully almost extinct, are alive and well in PAW. Then there is CINT, an attempt to write a C++ interpreter that can link to the ROOT classes, which unfortunately makes it very hard to link to the standard library classes and templates in C++ unless you stay away from CINT. In case you hadn’t figured it out, I personally believe ROOT has some very serious shortcomings. Others may disagree.

GETTING ROOT

That is the end of my rant against ROOT. I will not complain about it any more and we will use it a lot. The reason is that in spite of the above, ROOT works. It has been scrutinized by tens of thousands of physicists. Its inner workings are often wrappered versions of CERNLIB/PAW/HBOOK/MINUIT fortran code which has been scrutinized by hundreds of thousands of physicists. With the result that there are not very many scientific bugs. Also, ROOT is very extensive. There is a lot that you can do in ROOT that it is hard to find in other packages. The graphics classes allow you to build simple GUIs quite easily, and these GUIs include lots of functionality for science. Finally, because ROOT is open source, you can add your own functionality by compiling C++ code linked to the ROOT libraries. In the end, the positive aspects of ROOT, in my opinion, outweigh the problems. We will go the way of almost all high energy physicists, ignoring what is bad and enjoying and benefitting from what is good in ROOT.

You can download ROOT from http://root.cern.ch, the root homepage. The key links are in the frame at the left, including subversion, the users guide and the reference manual. For now let us focus on acquiring and building a version root used by the LIGO developers. It is important to note that some aspects of ROOT evolve rapidly, so having the right version is important.

We will download the root source code from a subversion repository. In your home directory, whilst connected to the internet, type in the following command:

$ svn co https://root.cern.ch/svn/root/tags/v5-20-00 root-52000

This downloads a copy of the root source code. It is nicer than ftp in the sense that if somebody changes the source code you can use svn update to get the altered code without having to download everything again. Also, if you were to want to make changes to the ROOT source, and Rene Brun decided that your changes were improvements, you could modify the repository code using svn commit. Note, however, that in the case of the ROOT repository, this is very unlikely to happen. In the case of the DMT, you may end up adding to or modifying the online source. Once you have the code, I suggest you change the name of the top directory from root to root-52000, then create a new directory root, also in /home/<username>. This is where we will install ROOT once it is built.

Building in linux is particularly simple. Follow the same technique as for g++, with a couple of caveats. First, you need to make sure that the path to the gcc and g++ executables is working. To do this type gcc --version, and the result should contain the version number 4.2.3 that you built from source. The same should be true of g++ --version. Next, you also need to check that the operating system knows where to find any runtime libraries (to be discussed below) used by gcc and g++. If you installed the compilers in

/home/<username>/myunixutilities, then the libraries are in the lib subdirectory of this location.

As for executables, the locations where the operating system searches for libraries can be controlled by setting an environment variable. In linux this environment variable is called LD_LIBRARY_PATH (quite a mouthful). It is not always set on a new system, so check whether it is set using echo $LD_LIBRARY_PATH. If it doesn’t exist or is empty, then set it, otherwise modify it to include the lib subdirectory. For the install location discussed above, the command is:

If LD_LIBRARY_PATH is empty or unset:

If LD_LIBRARY_PATH is already set:

If your install location for the compilers was not /home/<username>/myunixutilities, you will need to modify these commands accordingly. You can also add this line to your .bashrc file, as you did with the the PATH environment variable.

$ export LD_LIBRARY_PATH=/home/<username>/myunixutilities/lib

$ export LD_LIBRARY_PATH=/home/<username>/myunixutilities/lib:$LD_LIBRARY_PATH

The configure step for root is also slightly different than for previous packages. You first need to set the ROOTSYS environment variable to the directory where you want the root software to be installed, ensuring the directory exists and is empty. To do this, type, for example:

$ ./configure linux --enable-rpath --enable-soversion

The configure script for root was a home grown shell script - they did not use the gnu tools to autogenerate it. The rest of the build follows the pattern for gcc and g++. It is certainly worth using bash -c to launch the make step in a separate shell, since making root generates thousands of lines of output and any error that causes it to crash may occur many hundreds of lines before it finally exits. Compilation may well take over an hour.

Seminars for beginners with ROOT are available here.

$ export ROOTSYS=/home/<username>/root

Next configure ROOT using the following options. This line should also be included in your

.bashrc file before you build the DMT (see later).

Back to courses index