The new modular build system of OTB 5 organizes code into self-contained modules that have explicit dependencies. This improves on the previous system where code was organized into directories without clear dependencies, making it difficult for newcomers to add functionality. The new system uses CMake best practices and builds only enabled modules and their dependencies, allowing users to select what they want/need to build. Modules, including third parties, are now always built externally rather than having code contained within OTB.

1. Orfeo ToolBox users meeting and hackfest 2015
The new modular build system of OTB 5
OTB development team
3 - 5 june 2015, Toulouse

2. Motivations : the status with OTB <= 4.0
Code in directories but no real build dependency (cyclic dependencies between
directories)
Third parties : a maintainance hell (activation/deactivation, external/internal,
interdependencies)
Build system written in ancient CMake times ( version 2.4), no redesign since
then
Hard for newcomers to add new functionnalities without touching everything,
even more when introducing new third parties

3. Design choices
Let’s do it the ITK way : they faced the same issue a few years ago. The CMake
gurus did the work
State-of-the-art renewed CMake code : a bunch of new features, and ready for
later improvements
No more third party code inside OTB code (to the maximum extent...)

4. What modular means ?
The OTB classes are organized in self-contained directories called modules
One module contain headers, definitions, tests, applications, ... for all classes of
the module
Dependency tracking between modules is at the heart of the system : enable a
module and its dependencies are enabled automatically
Only build what you want/use
Third parties are also modules now
Modules are organized in thematic Groups (no real build consequences here)

5. How do I build OTB now?
Still with CMake, but way easier.
Less CMake options visible (unless you switch to advanced mode)
Better option naming, systematic : OTB USE XXX for third parties
Third parties are always external now. They can only be activated or not.
A default set of modules is defined

6. The internals
Module enablement evaluated in two passes
Modules which are activated
Third party deactivated, with all its dependees
BUILD DEFAULT MODULE
ON = all modules activated, except Mapnik and its dependees
OFF = you choose each enabled module with the Module XXX option
OTB USE XXX
Only for third parties
Easy way to disable a third party and all its dependees
Is evaluated after the first

7. What does a module look like ?
A directory in the Modules subdir :
otb-module.cmake and CMakeLists.txt file
include subdir : for .hxx files
src subdir : for .cxx files and a CMakeLists.txt. headers in here are not installed
test subdir : for tests
app subdir : for applications
See the Remote Module presentation for building a module from scratch in 5 minutes.

8. Hey wait !
I don’t care about your dependency hell, just build me the damned thing :
Superbuild (in a few minutes)
Can I reuse this for my work : Remote modules (in a few minutes)