SimpleITK/Design And Proposals/SIP 001

From KitwarePublic
Jump to navigationJump to search


JIRA Issue: SIMPLEITK-652

JIRA Issue: SIMPLEITK-649


SIP 001 - Refactor Superbuild for More Superbuild Projects

Introduction

We wish to add additional projects to the SimpleITK Superbuild to reduce inclusion of third party packages, and to improve the building time and building configuration flexibility. This is based on the request of system packagers to be able to utilize the system packages and reduce the third-party libraries included in SimpleITK's source code. Additionally, we wish to building the SimpleITK library once and then wrapping it multiple times. Specifically, we want to be able to wrap for multiple versions of Python with out having to do a "dirty" build in the same directory.

Comments

Brad Lowekamp: Comments can be made here


Remove ThirdParties

The third-party libraries of Lua and GTest are currently included in the SimpleITK source tree and distribution. This shall be removed from the repository, and become a dependency for the actual ( not Superbuild ) SimpleITK project.

The requirement of now requiring Lua may come as a surprise to users who are not using the Superbuild. They need to be encouraged to switch to use the SimpleITK Superbuild to provide these required dependencies. The Slicer 3D external project script for SimpleITK should serve as an example how a build can be updated to use the Superbuild.

Note: This item as already be completed.

Comments

Refactoring Wrapping for Modularity

The goal is to refactor the SWIG wrapping so that each wrapped language can be an independent project built against the SimpleITK project. This should enable the Swig wrapping to occur in the Superbuild level, or an additional build against SimpleITK common libraries for a different language version.

The current option to build the wrapped languages as part of the SimpleITK project should be maintained, but this will not be enable when building with the Superbuild.

This layout matches the installation and packages pieces needed for system packagers because it's a clear separation of the SimpleITK common libraries vs the wrapped languages. This clearly enables the use of CMake/CPack install facility to install and package the SimpleITK common libraries and headers. While the wrappings will have to be install and packaged according to the language conventions.

Another benefit of this separation is that it should enable work on a specific language more efficient. As the SimpleITK common libraries will not need to be rebuilt.

This work be done in three phases:

  1. Refractor the current Wrapping directory so that each language is in a separate sub-directory.
  2. Revise each language so that it is a CMake "Project" which will depend on and use SimpleITK.
  3. Refactor the code generation of the SimpleITK tests so that it can be used by the Wrapped language projects.
  4. Update the Superbuild to disable wrapping in the SimpleITK project but create additional external projects for each wrapped language.

Comments