Updates to the build system

Computational Model Builder (CMB)
1

After smtk 3.0 and cmb 6.0 are released, I would like to refactor how these two projects are built and tested. Here is a simplified description of the current design:

SMTK

  • contains a core library with unit tests
  • contains libraries that extend its functionality via external projects. Testing for these libraries is inconsistent (notably, Qt and ParaView extensions have very few unit tests in smtk; testing is deferred to the cmb project)
  • contains several modeling sessions with unit tests. Some of these sessions also contain extensions (whose testing is inconsistent for the same reason as above)

CMB

  • contains its own version of smtk (and exercises its unit tests during testing)
  • contains modelbuilder, an application derived from ParaView (essentially a stripped down ParaView). Testing has been light due to a) the rapidly changing feature set exposed in its API and b) the separation of feature implementation and feature testing between smtk’s paraview extensions library and modelbuilder
  • contains a PostProcessing plugin that conditionally reenables ParaView features in modelbuilder using a toggle
  • plugins built in smtk are directly linked to the application. This removes complications associated with plugin discovery, but is not extensible for other plugins
  • its installation constructs an incomplete product (no plugins, not transportable)

CMB Superbuild

  • builds dependencies for smtk and cmb
  • builds smtk, cmb (with its own smtk) and a whitelist of plugins
  • packages cmb with whitelisted plugins into a portable application

Plugin X

  • depends on smtk
  • creates a plugin .so that can be loaded into modelbuilder at runtime
  • no clear way to “fix up” the plugin for portability outside of adding it to the superbuild’s whitelist

This design has a couple of deficiencies:

  1. there is currently no automatic way to confirm that upstream changes do not break dependent projects that are not directly developed in-house
  2. separation of feature implementation and feature testing can result in having inconsistent coverage
  3. Any updates to our core libraries require a cascading set of updates to propagate fixes up the dependency stack
  4. The design promotes the development of features directly within our projects, resulting in larger, more monolithic base projects and making it more difficult to include software that cannot be incorporated within our projects (e.g. access-restricted, proprietary or GPL projects)

Here is my proposal for a new design:

SMTK

  • contains a core library with testing
  • If testing is enabled, cmb is added and built as an external project. Tests that exercise plugins construct a .plugins xml file listing the plugins needed for the test. A GUI test is then run with the environment variable PV_PLUGIN_CONFIG_FILE set to the generated plugins file.
  • If testing is enabled, there is also a user-augmentable list of external plugins (described similarly to projects in the superbuild). Each plugin is added as an external project and tested

CMB

  • no longer has smtk as a submodule
  • build does not require the smtk project; only ParaView and its dependencies are required
  • testing is restricted to the features that are implemented in cmb (e.g. the PostProcessing plugin)
  • its install rules will accept information about plugin targets (from smtk and from independent projects), copy the plugins into the install location and “fix up” the plugins for portability

CMB Superbuild

  • builds dependencies for smtk and cmb

Plugin X

  • depends on smtk
  • creates a plugin .so that can be loaded into modelbuilder at runtime
  • the project can be added at CMake configure time to smtk to make smtk build and run its unit tests
  • the project can be added at CMake configure time to cmb to make cmb build and package it

I am hopeful that these changes will promote the construction of smaller, more modular libraries while maintaining the benefits of unit testing and API contract enforcement from dependent projects back to smtk. Because plugins can be tested against an smtk build at CMake configure time, we can support continuous integration in both public and private testing environments that differ only in the set of plugins they exercise.

2

@Bob_Obara @dcthomp @johnt @Haocheng_Liu Please let me know what you think!

3

@ben.boeckel Please let me know what you think!

4

The new build system is encouraging and sounds the right way to do things.

@tj.corona Is any known drawbacks of the new build system or implementation road blocks?

5

@Haocheng_Liu I have only begun looking into implementing this design, but I don’t see any show stoppers yet!

6

@tj.corona I think this sounds like a huge improvement. My concerns are:

I think you mean: “cmb builds against an external SMTK provided by the CMB superbuild”?

Also, it’s unclear what happens when we need to bump both cmb and smtk at the same time… smtk could th perform contract tests of its own functionality, but how does cmb mr get tested against an smtk not provided by the superbuild?

7

Nope, I meant that the cmb project is perfectly buildable without any reference to smtk. Currently, modelbuilder takes things away from paraview but doesn’t add anything from smtk. As proof, I actually have a working branch of cmb where seldom is heard the word “smtk”.

Perhaps my first answer makes the second question moot?

8

One caveat to this design from @ben.boeckel:

In the (near?) future, we can look forward to the “FixupBundle” logic implemented in the superbuild to be available within CMake itself. Once that happens, plugins will be able to “Fixup” themselves, so the custom logic for installing/packaging CMB won’t be required. Much of the logic for its implementation will be borrowed from SMTK’s “test the following plugins” logic, though, and it may be nice to have CMB be able to bundle a viable modelbuilder complete with its plugins.