[vtk-developers] [ANNOUNCE] New module system landing

Ben Boeckel ben.boeckel at kitware.com
Mon Feb 4 09:49:20 EST 2019


On Sun, Feb 03, 2019 at 12:09:10 +0000, Andras Lasso wrote:
> I've used two large CMake-based projects in the past that tried to do
> something similar - guess which features to enable/disable based on a
> number of require/prohibit CMake flags. Both worked very poorly,
> because it always required lengthy experimentation with the flags to
> get the list of features that we  actually needed.

With the VTK module system, you say `YES` to modules you require. That
guarantees you the features you want. You may optionally say `NO` to
modules that you don't want for some reason (e.g., MPI or Python) which
guarantees that they do not build even via dependency resolution.

> The main issue is that positive (require) and negative (prohibit)
> requirements are obviously often contradict and it is not clear which
> one is stronger, why exactly they conflict, and what are the options
> to resolve the conflict.  Weak require and weak prohibit further
> complicate things with questionable benefits.

Both are exactly as strong and the module system refuses to continue if
the graph containing either cannot be made disjoint (mainly by disabling
testing bits of modules). Having only strong YES/NO makes it easy to
accidentally create a situation where I can't build anything without
turning MPI on (currently a supported configuration) since I can't say
"turn off MPI completely" if anything requires it since there's no "weak
requires" semantics.

> I would recommend to reconsider the introduction of this unusual and
> complicated 5-state system and only have binary REQUIRE on/off flag
> for each module. The build system would only include required modules
> and their prerequisites (everything else would be disabled).

This is what we had before and telling VTK to *not* build something
(e.g., I don't have an external dependency) was painful since it was
only ever a weak disable.

> If there
> was any conflict of required modules then the build system would print
> an error message explaining why the combination is not feasible and
> the the developer would decide how to modify the requirements.

Right now it says "X requires disabled module Y". What's missing is
information of the link between X and Y for figuring out how to fix it.

> Instead of VTK checking PROHIBITED modules, the external project that
> uses VTK can inspect the list of modules and throw a fatal CMake error
> if it finds that a prohibited module got enabled (it can display a
> much more informative message than VTK could, explaining why that
> module is not supported and what to do about it). ATTEMPT and AVOID
> can be similarly handled in the external project by logging a warning
> if the resulting module list is not optimal.

Why would any project care that VTK has modules that it doesn't use? The
only reason I can think of off-hand is a project not caring about such
things would be if it is providing conflicting symbols (e.g., the same
class) that VTK does in one of those modules. That's already fragile and
broken. For object factory issues, this issue should resolve things like
that:

    https://gitlab.kitware.com/vtk/vtk/issues/17218

> During configuration, a dependency graph can be printed (already
> available in CTK and used in most CTK-based projects for external
> project dependencies) to show how a component brings in other
> components. This helps the developer in deciding which modules to
> disable to get rid of prohibited or undesired modules.

Better debugging is on my list, but other tasks have higher priority
right now (though I can review other MRs doing this).

--Ben


More information about the vtk-developers mailing list