SBuild is a new, experimental build system for Slicer. It is based on getbuildtest2.tcl and genlib2.tcl, but rather than try to hid the gory details of building Slicer, SBuild attempts to expose a reasonable amount to the developer. The interface should be reasonably intuitive, but a brief walk through is useful. Click on the thumbnails for larger views. SBuild allows you to update and build just the portions of Slicer that you may require or want to build. Any of the required libraries may be specified to be build by SBuild, or to use an existing build. Existing libraries are not controlled by SBuild.

SBuild is a new, experimental build system for Slicer. It is based on getbuildtest2.tcl and genlib2.tcl, but rather than try to hid the gory details of building Slicer, SBuild attempts to expose a reasonable amount to the developer. The interface should be reasonably intuitive, but a brief walk through is useful. Click on the thumbnails for larger views. SBuild allows you to update and build just the portions of Slicer that you may require or want to build. Any of the required libraries may be specified to be build by SBuild, or to use an existing build. Existing libraries are not controlled by SBuild.

All-in-one Script to checkout and build Slicer3

There's a script called getbuildtest.tcl that makes the support libraries (VTK, ITK, teem, etc) and also builds slicer and does a dashboard submission. (Click here for background on getbuildtest and the experimental getbuildtest2 version).

Note: that a Slicer3-lib and Slicer3-build directory will be created for you. This is meant to be used to set up new machines and to run nightly testing of the full builds.

To run (all platforms):

./Slicer3-build/Slicer3

Note: the whole build environment takes about 2G of disk space.

Testing

Note also that getbuildtest will do an Experimental submission to the Slicer3 dashboard. If you want to use getbuildtest without submitting to the dashboard, you can set the test type to nothing with

getbuildtest.tcl -t ""

Other options for the -t (--test-type) option are Nightly or Continuous (or any of the CTest options).

What does getbuildtest.tcl do?

This script just automates the steps needed to build slicer. What you end up with is a set of source and build directories that can either be further manipulated with getbuildtest or can be worked with normally. That is, on windows you will have solution files that you can load in visual studio for debugging and further development.

Specifically, getbuildtest does the following steps:

Refreshes Slicer3 svn

Runs Scripts/genlib.tcl which does the following for each of the support libraries

For example, you may want a build against the ITK cvs head. Change the flag value and then run

getbuildtest.tcl --update

which will get the version from cvs, build it, and rebuild slicer3. Depending on how radically different the versions you build are, you may need to use --clean.

Another useful option is to change your build type to include support debugging.

set ::VTK_BUILD_TYPE "RelWithDebInfo"

options are Debug, Release, or RelWithDebInfo. RelWithDebInfo is a compromise between speed and debuggability. If you are tracking down a tough C++ bug you will get better information in Debug mode. After changing this flag, you should run

getbuildtest.tcl --clean

to create a completely new build.

Manual checkout/build of Slicer3 and support libraries:

Prerequisite software

You need to get and build the following packages if you aren't using the getbuildtest script:

SBuild

SBuild is a new, experimental build system for Slicer. It is based on getbuildtest2.tcl and genlib2.tcl, but rather than try to hid the gory details of building Slicer, SBuild attempts to expose a reasonable amount to the developer. The interface should be reasonably intuitive, but a brief walk through is useful. Click on the thumbnails for larger views. SBuild allows you to update and build just the portions of Slicer that you may require or want to build. Any of the required libraries may be specified to be build by SBuild, or to use an existing build. Existing libraries are not controlled by SBuild.

Binary downloads

Adding new Libraries to SBuild

The default package of SBuild contains the minimal number of required libraries to build Slicer. Currently no optional libraries are installed. The procedure for providing an SBuild plugin is modestly complicated, but several good examples exist. All plugins go in SBuild.vfs/lib/SBuildPlugins. As an example, let's create a plugin called Mythical, contained in SBuild.vfs/lib/SBuildPlugins/Mythical.tcl.

In the Slicer3/Scripts/SBuild directory, run ./bootstrap run to run SBuild, and ./bootstrap build to build the Tcl Starkits.

The Mythical plugin must append itself to ::SBuild(Plugins) to register, and declares itself optional, builds in order 100, and can use user provided builds.

Each plugin must provide several Tcl procs to do various functions. The naming convention is PluginName-Function-Architecture. In this example PluginName is Mythical. SBuild first looks for the -Architecture variant, and failing, calls the PluginName-Function. For instance, Mythical-Update is the Tcl proc that updates the source for Mythical, while Mythical-Build-Windows is a specialization for Windows. The important functions are: Update, Configure, Build, and ConfigureSlicer. The ConfigureSlicer function may append a CMake argument to be used when Slicer is configured. If external packages are allowed, the ConfigureExternal function is called. ConfigureExternal usually looks for libraries and sets a LibPath to be used to configure Slicer. Examples of these functions are shown below.