CMake refactoring P. Hristov 19/03/2014

History I  Recursive makefiles (F.Carminati):  Problems in dependencies  Slow  "Recursive Makefiles Considered Harmful" => flat makefiles similar to what Root team developed (B.Polishchuk, J.E.Revsbeck et al.): "Recursive Makefiles Considered Harmful"  Problem in dependencies if one removes files from the project  make –j… doesn’t work  Very often one has to clean the full project  CMake: considered for the first time after ALICE-FAIR Computing Meeting 04/2008 (see the backup slides)ALICE-FAIR Computing Meeting 04/2008 2

History II  CMake: first implementation in 2009, converted “flat makefiles” (F.Carminati, F.Uhlig)  complex processing macros, reusing lists from the “flat makefiles”  missing targets  CMake: second implementation in 2010 (J.Jose)  simplification  additional targets  first implementation of CTest/CDash (not completed)  CMake: production version (A.Goel, S.Tangudu)  all targets  reimplementation of CTest/CDash (not completed)  more simplifications, improved macros 3

CMake: current status 4  After 3 years in production it is time to evaluate the situation  The parallel build is working in most of the cases  Still some issues with the dependencies  In case one uses GLOB  For header files that are copied in include subdirectory  In case of changes in the installation place  We are not able to profit from the automatic project generation  Often recompilation triggered by the current versioning

CMake: current status 5  Several targets are error prone and often need manual intervention, i.e. the RPM generation for DA and AliMDC, PAR files  Custom SPEC files created via “echo”  The dependencies are not tracked, the compilation always starts from the beginning  The version of the RPM has to be improved  The static build is not fully operational: the library is prepared, but the static AliRoot executables are not OK  The code checker and the reverse engineering tool are not operational (problem with some software the depend on)

CMake: ideas for refactoring 6  Configuration  Avoid the use of obscure environment variables (ROOTSYS, ALICE_ROOT) as “hardcoded places”  Improve the FindXXX functions. We have also many examples outside of AliRoot: FairRoot, ROOT, Geant4, AMORE, etc.  Use as much as possible templates (something.in) for creation of files (SPEC, PAR, installation scripts)  Re-implement the AliRoot versioning and introduce requirements on the versions of the external packages (ROOT, Geant3, Geant4, BOOST, CGAL, FASTJET)  Introduce feature-based compilation, i.e. if we do not have FORTRAN compiler, switch off the compilation of some modules.

CMake: ideas for refactoring 7  Structure: use “native” CMake style (see the CMake tutorials):  One sub-directory per library/binary with the same name (i.e. libSTEER  STEER, aliroot  aliroot), or with the original name if it exists  No GLOB…, use recursive add_subdirectory with explicit list of subdirectories  better tracking of dependencies  Explicit list of source files  Possibility to use library-specific compilation options  Explicit inter-library dependencies in the list of include directories  Possibility to build in any location  Creation of distributions with CPack: RPM, deb, …  Possibility to generate projects: Xcode, MS Visual Studio, Kdevelop, etc.  Possibility to generate rootmap files for automatic loading of libraries  Use of CTest/CDash

CMake refactoring: prototyping 8  In preparation for ROOT6 a prototype for the updated CMake build system was created in r6dev branch  Includes most of the modules and libraries  Some of the ideas on the structure are already implemented  The copy/paste approach has to be replaced by functions/macros  The build is significantly faster  Several targets have to be (re-)implemented  PAR files  Detector algorithms  Static build  Rule checker  Documentation  CTest/CDash

Plan 9  Start after the v5-05-Release  Move the code of each library/binary in the corresponding subdirectory. Modify the “old” CMake build system at this stage  Check other packages with CMake build for ideas and code  Improve the FindXXX functions: can be done in parallel  Implement the new functions, macros and templates: can be done in parallel  Re-implement existing targets  Branch from the master and prepare the replacement of *.pkg by CMakeLists.txt for each library/binary  Estimated time: one month with two people  Your help is very welcome!

Backup 10

FAIR-Alice WorkshopF.Uhlig 11 CMake - What is it? Open source project (BSD style license) Family of tools to build, test and package software Meta build tool generates input for native tools –UNIX Makefile –Xcode –Visual Studio 6,7,8,9 IDE files –KDevelop –Eclipse Who is using it? –KDE, Scribus, SecondLife, ITK,VTK, FairRoot ;-) Who is behind CMake –Kitware, Los Alamos National Labs, Sandia National Labs, National Library of Medcine, NAMIC

FAIR-Alice WorkshopF.Uhlig 12 CMake Features Support complex custom commands –Generate code during build process which is then compiled (e.g. rootcint) –RuleChecker –Doxygen Optional component support (turn on/off features) Shared library and DLL support (version support) Single and simple input format for all platforms Automatic dependency generation (C, C++, Fortran) –Full dependencies: build a target in one directory, and everything this target depends on will be up to date Parallel builds (if supported by the native tool e.g. gmake -j4) Out of Source builds Linux, Mac OS X, SunOS, HPUX, IRIX, Windows, etc. Simple marco language Only depends on compiler and native build tool

FAIR-Alice WorkshopF.Uhlig 13 CMake Features (cont.) Color and progress output for make Automatic rerun of cmake if any cmake input file changes Graphviz output for visualization of dependency trees Works with parallel make and on build farms make help shows all possible targets in the directory make foo.o build only foo.o and everything foo.o depends on CMake has a GUI layer for easy editing of input variables CMake has a command line interface Cross compiling support (CMake 2.6)