CMake refactoring. P. Hristov 19/03/2014

Transcription

1 CMake refactoring P. Hristov 19/03/2014

2 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.): 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) 2

3 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

4 CMake: current status 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 4

5 CMake: current status 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) 5

6 CMake: ideas for refactoring 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. 6

7 CMake: ideas for refactoring 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 7

8 CMake refactoring: prototyping 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 8

9 Plan 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! 9

10 Backup 10

11 FAIR-Alice Workshop F.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

12 FAIR-Alice Workshop F.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

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) FAIR-Alice Workshop F.Uhlig 13