Slicer3:Build/Test/Deploy

From Slicer Wiki
Revision as of 17:57, 15 May 2008 by Marianna (talk | contribs) (1 revision)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Home < Slicer3:Build < Test < Deploy

CMake Build System

(Notes from Nicole, Katie, Andy at NAMIC AHM)

We would like to preserve current slicer2/Scripts/cmaker.tcl and genlib.tcl functionality through the move to cmake. As well, some additions are proposed to extend our building options.

Slicer Base and Modules

Support current capabilities:

  • cross platform compatibility
  • one command build of Base and Modules
  • ability to easily build a single Module
  • ability to easily build a subset of Modules
  • integrate with the launch system for auto detection and loading of base and modules (support for modules without compilable code) (currently done via including the slicer_variables.tcl file)
  • support dependency of modules on slicer base (currently done via CMakeListLocal.txt file in the module subdirectory)
  • support interdependencies between Modules
  • ability to suppress modules from being built/run
  • support dependency of modules on support libraries - third party or in Lib or in na-mic sandbox
  • easy to add new modules (or a least provide a process document)
    • translate from vtkCustomModule
  • ability to separate make and cmake


Extensions:

  • Cross platform:
    • ability to mix and match between OSes and compilers for testing
    • automatic (ie from ITK) support for new compilers
  • Installation:
    • ability to have slicer binaries install somewhere other than inside the build tree
    • option for Unix style lib/bin/man directory structure or Windows style Program Files directory structure
  • make build process more robust (i.e. deal gracefully with modules not compiling, cvs repositories down, etc.)
  • ability to take automatically advantage of multiprocessor machines (i.e. -j option)
  • fine-grained control over steps in the build
  • Fast turnaround time on changes to the build process (either by Slicer developers or by Kitware)
  • move away from having a slicer_variables.tcl file, while retaining global specifications



Support Libraries

We need a mechanism to allow developers to set up a fresh computer with all supporting libraries before they start to compile and work on slicer. Currently this is provided by slicer2/Scripts/genlib.tcl but it needs to be reworked. Most of the requirements are the same as the slicer Base and Modules ones, here are extra ones.

Support Current capabilities:

  • will skip over already built libraries
  • specify default version tags for cvs checkout

Extensions:

  • failsafes for cvs outages
    • possibly host/mirror at BWH for better download speeds
  • usable by a novice developer (better error messages)
  • ability to test against nightly cvs for a single library
  • easy to add a new library

Packaging

  • CPack will be used
  • CPack will be augumanted with the current Slicer packaging (tarup.tcl), where tarup.tcl will do all the necessary library dependency searching and CPack will package into TAR, DEB (Debian Linux), RPM (Red Hat, Fedora, or Mandrake), and NSIS (Windows).