Leadership:Slicer3-compilation-2008

Introduction

This page is intended as a blog for our discussions about the organization of the Slicer3 compilation setup. As Slicer 3 is emerging from beta we need to reorganize how we compile and distribute the software.

• We need to
  • review the current situation
  • identify how it should be done
  • develop a plan to get there

Excerpt from the Specific Aim 1 of the Service Core of the grant application

...In particular we will support configurations instantiated from combinations of the following possibilities.

• Hardware (in both single and multi-processor combinations): Intel 32- and 64-bit CPU’s, AMD 32- and 64-bit, Sun SPARC
• Operating Systems: Linux, Windows 2000, XP, Longhorn, Mac OS X and later, Solaris
• Compilers: gcc, Intel, Borland, Sun CC, MS Visual C++ 6.0, .NET, Sun CC

• These resources will be available to NAMIC via a dedicated high-speed communication line. Although we expect that many NAMIC scientists will use their own resources for local development, the computational infrastructure provides the means to compile, test, and disseminate software on platforms to which that particular site might not normally have access. This is particularly important for cross-platform development as the ability to simultaneously develop software on a variety of configurations insures that the development process remains effective.

• Sufficient disk storage and backup resources will be deployed to archive data and support the dissemination and training cores. A server will be configured and dedicated specifically to support NAMIC collaboration resources and facilitate communications with the project management core.

Current Situation

All build systems in slicer have been based on cmake since it was introduced. CMake addresses compile options and project dependencies but does not address accessing source code repositories (cvs/svn).

slicer2

The following scripts were developed for slicer2:

• genlib.tcl generates all the libraries (tcl, tk, vtk, itk) including cvs/svn checkout, configure, and build.
• cmaker.tcl updates, configures, runs cmake and invokes the copiler
  • the slicer base
  • on each of the modules
• tarup.tcl which assembled all libaries and resource files into a distribution bundle.

Note that the module discovery process cmaker and tarup was identical to the one used by slicer2 at starup. This allowed a unified approach to module development and deployment.

Modules in slicer2 are based on the tcl package facilities which provided a clean layering of dependencies and modularity of both C++ and tcl code.

slicer3

Slicer3 started a new KWWidgets application framework for which the modules are being reworked (see Slicer3:Loadable_Modules).

The genlib and cmaker scripts were combined in slicer3 into a single script called getbuildtest.tcl. getbuildtest also invokes ctest to run tests and submit to the dashboard, and also has options to build in release mode.

How it will be when we are done

• .exe for windows
• .deb .rpm and ... for linux
•  ?? for mac
• use directory tree in http://www.slicer.org/Downloads for webpresence

How we will get there

Sebastien, Will, Steve, Katie, Stephen, and Brad met at the AHM to evaluate options. After much consideration we decided on some general goals and specific plans.

• Goals:
  • We would like a user centered installation process that simple and efficient (users in this case means the customers of NA-MIC who would like access to the NA-MIC kit as either a binary or as a source code platform for implementing their own solutions -- wherever possible the same interface should provide easy upgrade from binary to source installations).
  • We would like to move from a slicer-custom set of utilities to a standardized, cmake-based solution that would provide the advanced features for use by various projects.
  • We want to work on new functionality rather than reimplementing existing solutions. I.e. focus on developing the cmake-based build process for modules before rewriting getbuildtest.
  • In the end we would like something called "NAMICSetup" akin to the setup.exe program for cygwin or the synaptic package manager for linux that would allow download/install of libraries and programs. In addition though we'd like NAMICSetup to allow customized builds with the following types of options:
    • build debug or release
    • build against releases or cvs heads of various toolkits (ITK, VTK, etc)
    • enable/disable features (e.g. python or libxml2)

To this end, we held a tcon on January 28, 2008 between Steve, Alex, Terry and Sebastien to coordinate the efforts of the Slicer3:Loadable_Modules and [1] projects.

Terry is working on changes to slicer3 internals to support module loading. Sebastien is working inside CMake to support customized builds of slicer3 modules (in particular adding svn/cvs support to CMake).

With this infrastructure in place Steve and Wendy will review the user requirements for a command line and GUI interface to simply the build and install process. Dan Blezek has also begun prototyping what the GUI interface could look like.