Current Membership:  Joanne Bogart, Toby Burnett, Jim Chiang, Navid Golpayegani, Heather Kelly, Tracy Usher 

Charge

Address the deficiencies associated with CMT by proposing an appropriate set of patches and workarounds with deployment plans, or determine that the issues are too numerous and a new system should be utilized.  In either case, changes will be introduced incrementally and will work in parallel with our current system.

CMT Functions

  • Checkout code from CVS and handles our package structure
  • Generates Makefiles and Visual Studio project files for building code
  • Generates setup scripts suitable for setting up the environment to run applications 

Target Audience

Who uses CMT?

  • Developers
  • Pipeline Jobs
    CMT is used to setup the environment and run applications.  Often the pipeline runs an ad hoc set of packages that are not necessarily from one specfic tag of GR.
  • User/Developers
    Some continue to use CMT to set up the environment to run applications even in "user" mode.  At times user/developers desire newer tags of packages not yet available in a tagged release.

True end-users should not be using CMT, rather they should use the distributions packaged and available from the installer.

Affected Tools 

  • MRvcmt
    completely tied to CMT, there will be no migration for this tool
  • MRStudio
    written to allow removal of CMT, but we must retain the package structure of our code
    Currently MRStudio uses CVS for checkouts, but uses CMT to get list of packages for recursive checkouts
    CMT also provides the list of tags for a package
    VS2003 solution files are generated without CMT, but is used to determine dependencies.
  • RM
  • installer
  • glastpack
    uses CMT directly - if CMT is abandoned this tool needs to be re-written or we'll need MRStudio's command line tool
  • pipeline
  • workbook
    Directions for checking our code and building may need to be revised.

Requirements/Goals

A new system must demonstrate that it works first, and must work in parallel. This would apply to each stage of a multi-stage transition.

  • There must be a suitable migration plan for all affected tools including time estimates for completion.
  • System must be customizable to meet future needs.

Package Mangement

  • Handle checkouts using our existing package structure including containers.
  • Address dependency explosion
    Ability to express library/application dependencies within a single package, such that library A and library B created in the same package can have A depend on B.
    Ability to control what libraries are linked to your constituents from "used" packages.  CMT links all libraries from used packages to all constituents within the package that depends on it.
    Review structure for unit tests to reduce dependencies.
  • Reduce the number of environment variables generated to just those we truly need.

 Builds

  • Generate usable Makefiles and Visual Studio files for all of our supported systems
    Should be intelligent enough to rebuild only those constituents that are necessary
    Include debug symbols for true debugging capability
  • Allow for compile of single files within projects 
  • Handle builds using our existing package structure including containers
  • Provide a system that RM can utilize as well for its builds, so that developer compiles and RM builds are more consistent.
  • Would like to generate wrapper scripts as part of the build process, rather than having RM perform this function.

Interfaces

  • Command line.  This should serve needs of Installer, RM, Pipeline and interactive users who prefer a command-line interface such as glastpack (I am not in favor of porting glastpack, but the command line interface we end up with must have at least the functionality of glastpack). It should be possible to checkout, configure (where 'configure' means 'get ready to build', not necessarily identical to CMT configure) and build by individual package or recursively. There should be a simple way to invoke executables (minimal setup required) with or without a debugger. Ability to directly invoke makefiles (on Linux/Mac...not sure if there is a useful Windows equivalent) would be a plus.
  • GUI.  Should have all the functionality listed above for command-line. Ideally this should be built on the same kernel as the command-line interface (MRStudio model).
  • Context switching. Currently (e.g. via MRvcmt) it is possible to quickly switch from one arena to another by changing CMTPATH and perhaps (CMT) tag.  This ability should be preserved.  Ideally it should also be possible to do development within two different contexts (in different processes) concurrently.

References

https://confluence.slac.stanford.edu/display/core/SCons+alternative+to+CMT

https://confluence.slac.stanford.edu/display/core/CMT+Problems

  • No labels