[vtk-developers] vtk-8.2.0-rc2 problem building wheels

Ben Boeckel ben.boeckel at kitware.com
Mon Dec 17 16:13:51 EST 2018


On Mon, Dec 17, 2018 at 15:07:35 -0500, Matt McCormick wrote:
> To explain more explicitly, the VTK module that was generated by
> ParaView would have the following in its CMake package configuration
> code:
> 
> ```
> # This prevents recursion issues
> if(NOT ParaView_SOURCE_DIR)
>   # This make sure we load the ParaView configuration the module was built from
>   set(ParaView_DIR \"${ParaView_BINARY_DIR}\")
>   find_package(ParaView REQUIRED QUIET NO_MODULE)
> endif()
> ```
> 
> where "${ParaView_BINARY_DIR}" is substituted during ParaView's
> configuration, like the "export_code" for third party libraries.

I'd prefer that we just not need these hoops. ParaView's VTK modules
live under ParaView in the new build, so it isn't an issue there at all
anymore.

> If a project that depends on VTK and only calls
> 
> ```
> find_package(VTK COMPONENTS VTKModuleThatPublicallyDependsOnQt)
> ```
> 
> how does the new module system load the Qt CMake package configuration
> so CMake knows about the Qt build and its imported targets? That is,
> is there an equivalent of `vtk_module_export_code_find_package`?
> Similarly, if another VTK module depends on a third party library, and
> the build is set to use the system's build of that library as opposed
> to VTK's build, how does it load the CMake package configuration for
> the third party library?

Using `vtk_module_find_package` will export the `find_package` into the
`VTK-module-find-package.cmake` file. This finds the dependency only if
the module requiring it is requested (explicitly or via a dependency).
It supports components, version checks[1], etc. Other than that, the
only generated code by the module system is for adding module properties
to targets (dependencies, hierarchy file paths, header locations, etc.).
Code injection needs to be provided in the `foo-config.cmake` file which
is not handled by the module system at all.

> Yes -- we are talking about providing the package / module dependency
> resolution of the system, which is not provided by CMake, and using
> CMake's build system in a consistent way, as opposed to a secondary
> build system.

I'm confused. I thought you were mentioning providing an encapsulation
for the ~150 lines that VTK has in its top-level CMakeLists.txt (finding
module files, scanning them, building them, wrapping, handling the
vtk-config.cmake file, etc.). That infrastructure is not provided by VTK
and nor, IMO, should it. Dependent projects will still need to do those
100+ lines in order to be a "proper" project and provide something for
`find_package` to work well.

> > Then, IMO, these should just be separate repositories and optionally
> > remote modules rather than inside of VTK's repo. If they're "usually"
> > going to be built separately, just make them separate to begin with.
> 
> Yes, that's right.

OK, that sounds fine with me. What I'm not OK with is a module inside of
the vtk/vtk repository supporting an independent build. So I guess this
means that `RenderingOpenVR` will be moved out somewhere else then?

--Ben

[1] This is a bit complex due to version requirements of different
projects. For example, say VTK has some modules which require Boost
1.41. If it finds 1.51.0, at install time the *exact* version must be
found, so it gets forwarded as `find_package(Boost 1.51.0 EXACT)` even
though the build does `find_package(Boost 1.41)`. Qt has a similar thing
where the major.minor version built against is now the minimum version
rather than the build-time requirement.


More information about the vtk-developers mailing list