Version 2 (modified by 12 years ago) (diff) | ,
---|
Design
Proposal for CMT2.
(2011/12/13)
Several developments and studies have taken place around the issue related with Configuration & Build Tools
- Work by Marco et al & CERN around the Gaudi Framework (including the new framework)
- Work by Sébastien around Mana (Atlas) + WAF
- Work by Christian around a CMT-like layer on top of CMake
- Optimization developments for CMT itself by Grigory, in the direction of a project build, and reducing the internal overhead factors during the CMT-based build.
It’s time now, considering the long term schedule (mainly considering the long shutdown of LHC) to decide on a transition phase for this project:
stopping the R&D phase => entering the development phase.
So far, my vision of the possible scenarii is as follows:
- Continuation of the optmizations for CMT until the native CMT build reaches a level of performance equivalent to (or close to) what can be obtained ‘manually’ by using CMake or Waf
- Developing a completely new tool.
General comments:
A priori, scenario 2 is needed in any case, since several important requirements (wide portability, support of IDEs) will anyway be expected, while cannot be obtained but with a very large development team. Moreover, those requirements are much better realized if based on an external toolkit for reason of maintenance and future evolutions.
Comments on scenario 1
This is appropriate only if this is achieved on a relatively short planning (order of 2-3 months)
Comments and issues on scenario 2
The requirements for such a development should consider
- The conclusions of the configuration review done in Atlas
- The current list of candidate tool (CMake, WAF)
One proposed architecture for the new tool should permit us to:
- Select (or design) a declarative language for the configuration parameters
- Select an architecture of packages/projects for the software base supported by the tool
- Implement a set of utilities based on this language so as to:
- Let users specify configuration parameters for packages/projects/use cases
- Interactively query the configuration (optionally with a GUI?)
- Deduce from the set on specified parameters the operational parameters needed to build the software, test it, deploy it, configure the run time environment
The architecture should be implemented onto a well adopted tool kit offering:
- High level of performance in the build process
- High level of portability across systems/IDEs
- Programming flexibility
- Good level of confidence on its future
Comments
- So far, the candidates for implementation are CMake and WAF
Proposed schedule:
- Organize a decision meeting mid January at CERN