Table Of Contents
Previous topic
Building tarballs for use on clusters or the grid
Building tarballs for use on clusters or the grid
In cmake/tools there are a collection of .cmake files that are each responsible for detecting a tool and configuring the build to use it correctly. The rest of the cmake infrastructure ‘uses’ tool via several cmake variables. For a tool ZZZ,
ZZZ_INCLUDE_DIR:
The include directory that should be passed to the compiler via the -I flag. This directory should normally contain one subdirectory with the name of the tool at the top of the path, unversioned, e.g. boost_INCLUDE_DIR should equal /path/to/boost-1.36/include, and that directory should contain only a subdirectory boost, so that when reading code it is obvious which tool is responsible for what headers (eg:
#include <boost/shared_ptr.hpp>And so that a change in version of a tool doesn’t require rewriting any #includes in client code. Note that:
#include <shared_ptr.hpp>Which could come about if the INCLUDE_DIR were one level deeper, is incorrect, as it isn’t obvious what tool that header file comes from. (In the case of shared_ptr.hpp it isn’t so bad, but try to track down globals.h in a workspace with ten or fifteen tools configured. Not fun.)
ZZZ_LIBRARIES:
A list of libraries to link to. This is a semicolon-separated list of full paths to libraries, cmake-style, not just the names of the libraries.
ZZZ_BIN_DIR:
Not often used but available if the tool provides executables for some reason.
ZZZ_FOUND:
A flag needed by the rest of the build system to know that detection of ZZZ succeeded.
Note that there is a cmake macro tooldef which will automate a bit of this.
Most tools are detected are expected to be found in I3_PORTS, and system-installed versions are ignored. If you define SYSTEM_PACKAGES, the cmake flag NO_DEFAULT_PATH is omitted and system-installed packages may be used if versions installed from I3_PORTS cannot be found. This is an experimental feature and may cause problems in the event of version conflicts, but this option can speed up builds by avoiding the need for an I3_PORTS Qt or allow operation of Icetray on systems not supported by the ports tools.
Site specific handling of tools is supported as follows:
For each tool T, the directory /usr/share/fizzicks/cmake (yes, that is really the path) is searched for T.cmake and if this file is found, it is read in lieu of the standard tool definition file. This directory can be overridden by setting I3_SITE_CMAKE_DIR in your environment.
For instance, an override for tool python (filename python.cmake) might look like:
set(PYTHON_LIBRARIES "$ENV{HOME}/lib/libpython2.6.so" CACHE FILEPATH "Python library")
set(PYTHON_INCLUDE_DIR "$ENV{HOME}/include/python2.6" CACHE PATH "Path the Python include directory")
set(PYTHON_EXECUTABLE "$ENV{HOME}/bin/python" CACHE FILEPATH "Python interpreter")
set(PYTHON_VERSION "2.6" CACHE STRING "Python version")
set(PYTHON_FOUND TRUE CACHE BOOL "Python found")
Note the $ENV{HOME} sytax used in the example: since CMake doesn’t automatically mix in environment variables from the shell, you have to be explicit when substituting values like HOME.
Warning
If you use a nonsystem python as above, your toolset (specifically the boost_python component of the boost tool) must be built against that same python. See the page for the Python for more information.
Q: Hello, I tried to install a new toolset and ran a problem at compilation. It failed as follows:
g++ -shared -Wl,-soname,libGX11.so.5.18 -m32 -O2
-Wl,-rpath,/home/sabrina/work/new_tools/root-v5.18.00/lib -o
lib/libGX11.so.5.18 x11/src/GX11Gui.o x11/src/Rotated.o
x11/src/TGX11.o x11/src/gifdecode.o x11/src/gifencode.o
x11/src/gifquantize.o x11/src/G__X11.o -lXpm -lXext -lX11 -lXft
/usr/bin/ld: cannot find -lXft
collect2: ld returned 1 exit status
It seems that there is a missing “-lXft”. Does someone have an idea what “lxft” is and where can I find it?
A: That thing is a linker flag. -l___ means to find lib___.so and link it in. Googling around for Xft and libXft reveals that this is the X FreeType library. This is a system package, you’ll need to install it to proceed.
If you are on ubuntu, the general procedure is to search though the packages for the library name that is missing. If you find one that ends in -dev, this one is likely to contain the missing headers/libraries. In this case there is indeed a package libxft-dev. Install it via synaptic or the like.
On redhat or others, you’re on your own. You can try downloading and installing tarballs manually.... good luck.
Q: We tried to install the tools on SL5.2 and the installer keeps complaining about missing X11-devel headers, but the packages are installed. does anybody know, how to solve this? the error message is: “Please install the X11 developer headers for your platform, configure: error: Broken X11 install. No X11 headers”, though the package libX11-devel-1.0.3-9.el5 is installed
A: the header x11/intrinsic.h was missing, which is included in libXt-devel