= 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:
 1. 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
 1. 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