source: CMT/v1r19/doc/Design.txt @ 1

//-----------------------------------------------------------
// Copyright Christian Arnault LAL-Orsay CNRS
// arnault@lal.in2p3.fr
// See the complete license in cmt_license.txt "http://www.cecill.info". 
//-----------------------------------------------------------

==========================================================================
Flow in cmt_parser

--------------------------------------
Cmt::parser (command_line)
  split command line into a vector of args
  call parser (args)

--------------------------------------
Cmt::parser (args)
  init ArgParser
  call clear
  call configure
  set m_current_access to user or developer mode
  parse_arguments
  handle extra lines or extra requirements

  call use_cmt and use_home is needed
  select recursive
  reach current package and call use_user_context if needed

  detect error if needed

  execute action


--------------------------------------



==========================================================================
Gestionnaire de messages de log dans CMT
----------------------------------------

cmt_log (...)

will

o display or not according to the level of output

   [default] quiet
   verbose = <n>
   debug

o pour le mode debug on devrait rajouter la fonction??

A terme doit remplacer tous les outputs de CMT !!!


==========================================================================
1) actions in CMT [DONE]
-----------------
Principle:
  define an "action" concept similar to constituents (or macro????)

  - it has a name

  - its name corresponds to a make target

  - it receives in its value a shell command (subject to macro
  expansion before activation)

  - can be run out of the make context through the "cmt do <action>" command.

  - in the context of gmake a temporary make fragment will be
  generated, holding the associated shell command.


examples

action A "xxx" WIN32 "yyy"

=> the syntax is like macros but the execution phase is close to constituents.

One may either do 

> cmt do A

or

gmake A

Question : do we need parameters

action A "xxx<p>" WIN32 "yyy<p>"
action A "xxx$(p)" WIN32 "yyy$(p)"

so that 

> cmt do A p=z
> gmake A p=z

Question : can action replace setup_script ?

Implementation : reuse the symbol code.

Cmt::do_do (...)
  o at least first argument should be the action name
  o optional param-value pairs will assign value to macros

     cmt do A p=y

    equivalent to [macro p "y"]

cmt show constituents should show actions as well

when generating the constituent make files we also have to generate
makefiles for actions.
=> name space for actions share the name space for constituents
=> there is a target_<action> tag [see next design]

Actually, doing

action A "cmd"

is equivalent to doing:

document cmt_action_runner A action_value='cmd'

==========================================================================
2) target tags DONE
--------------
Principle:

  - Each constituent (or action) is associated with a make target

  - let's also generate a "tag" associated with the make target.

  - the tag format is target_<name>

  - the group tags are also defined as tag associations

      tag target_all target_A target_B

==========================================================================
3) A pattern also defines a dynamic CMT keyword.[DONE]

 => at the end of the parser if the word did not match any standard
 CMT keyword, then we look into the pattern name space.

ex. 

pattern A ...

apply_pattern A p=x

is equivalent to 

A p=x

==========================================================================
4) Revival of the concept of Project[DONE]

o One project is associated with every CMTPATH

o Strategies are stored into project objects

o project objects are ordered like CMTPATHs

o Each CMTPATH entry does generate one Project

o unnamed projects receive a default name [TBD]

o Projects can be named:

   project abcd

   Will name the project associated with the cmtpath of the package where this is defined.

o By default Projects inherit properties of the previous project

o Any package has a corresponding project which is the project
associated with the CMTPATH entry of this package.

o CMT itself defines the "base" project (named CMT)