Changes between Initial Version and Version 1 of Design

Timestamp:

Dec 13, 2011, 11:38:07 AM (12 years ago)

Author:

/C=FR/O=CNRS/OU=UMR8607/CN=Christian Arnault/emailAddress=arnault@…

Comment:

--

Design

@@ +1 @@
+= 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, 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 schedules (mainly considering the long shut down of LHC) to decide on a transition phase for this project: stopping the R&D phase and 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 developers 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
+
+