|
|
| Line 1: |
Line 1: |
| − | == CMake Build System ==
| + | <big>'''Note:''' We are migrating this content to the slicer.org domain - <font color="orange">The newer page is [http://www.slicer.org/slicerWiki/index.php/Slicer3:Build/Test/Deploy here]</font></big> |
| − | | |
| − | (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
| |
| − | | |
| − | <br /> | |
| − | | |
| − | 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
| |
| − | | |
| − | <br /> | |
| − | | |
| − | <br />'''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).
| |
