Abstract
ROOT is a large code base with a complex set of build-time dependencies; there is a significant difference in compilation time between the “core” of ROOT and the full-fledged deployment. We present results on a “delayed build” for internal ROOT packages and external packages. This gives the ability to offer a “lightweight” core of ROOT, later extended by building additional modules to extend the functionality of ROOT. As a part of this work, we have improved the separation of ROOT code into distinct modules and packages with minimal dependencies. This approach gives users better flexibility and the possibility to combine various build features without rebuilding from scratch.Dependency hell is a common problem found in software and particularly in HEP software ecosystem. We would like to discuss an improvement of artifact management (“lazy-install”) system as a solution to the “dependency hell” problem.HEP software stack usually consists of multiple sub-projects with dependencies. The development model is often distributed, independent and non-coherent among the sub-projects. We believe that software should be designed to take advantage of other software components that are already available, or have already been designed and implemented for use elsewhere rather than “reinventing the wheel”.The main idea is to build the ROOT project and all of its dependencies recursively and incrementally, making it fundamentally different than just adding one external project and rebuilding from scratch. In addition, this allows to keep a list of dependencies to be able to resolve possible incompatibility of transitive dependencies caused by the versions conict.In our contribution, we will present our approach to artifact management system of ROOT together with a set of examples and use cases.
Highlights
During the different stages of development, through the years ROOT [1] was using various build tools to manage its code, starting from custom build tools going through recently-removed Makefiles and currently using CMake [2] – a cross-platform buildgenerator tool.Programmers love to hate build systems
It is evident that there were a lot of efforts done by the ROOT team to modernize ROOT CMake code and provide a stable and reliable support for ROOT build system [4]
This paper gives some insights of used good practices and what they allow users to do beyond building and shipping ROOT in the standard way
Summary
During the different stages of development, through the years ROOT [1] was using various build tools to manage its code, starting from custom build tools going through recently-removed Makefiles and currently using CMake [2] – a cross-platform buildgenerator tool. Following the talks from notorious developer’s gatherings and conferences, often build systems and CMake in particular is ridiculed [3]. A set of Modern CMake tutorials are developed to encourage good practices among the developers’ communities. They suggest to start treating CMake as code and think in targets, use properly CMake interface targets either for exports or imports. ROOT is no different, even though the CMake build system is rather new development it can be improved. Using community good practices addresses variety of problems of ROOT build and installation procedures. It is evident that there were a lot of efforts done by the ROOT team to modernize ROOT CMake code and provide a stable and reliable support for ROOT build system [4]. This paper gives some insights of used good practices and what they allow users to do beyond building and shipping ROOT in the standard way
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
