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

[Matt McCormick]

On Mon, Dec 17, 2018 at 1:42 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:
>
>
> > > The old module system globbing for this information has
historically not
> > > worked out well. I don't want to continue that mistake.
Concretely, in
> > > an install of ParaView, `find_package(VTK)` didn't work
because ParaView
> > > modules were included in VTK's glob and assumed
variables were set that
> > > only ParaView's config provided. This errored out and
made it impossible
> > > to use without setting a magic ParaView variable before
finding VTK.
> >
> > It sounds like the VTK modules created by ParaView needed to call
> > find_dependency(ParaView) like third party modules do that
defer to the
> > configuration of system versions of libraries.
>
> They couldn't have. It would end up in a recursive loop (ParaView found
> VTK too).

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.


> > We support using third party libraries because there is a practical need
> > and desire to use them. There may be bugs in third party software. If there
> > are bugs in the third party software CMake configuration, then that
> > software cannot be used until it is fixed. If there is a bug introduced by
> > a third party VTK module, then that module cannot be used. I do not think
> > it is a show-stopper.
>
> AFAIK, it was supported because that was the *only* way VTK managed
> modules after installation. That's no longer the case, so with the new
> build system a "practical need and desire to use them" is gone since VTK
> isn't special for itself anymore. That is, `find_package(VTK)` works
> just like `find_package(Boost)` now. Projects which want to install an
> SDK can do that too; VTK no longer stands in their way.

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?


> > > Yes, that is not "a few lines". It involves finding VTK, scanning
> > > modules, making sure that the found VTK provides the required modules,
> > > building modules, optionally wrapping, installing CMake configuration
> > > files, etc. And that doesn't include packaging.
> >
> > CMake functions to do all these things could be encapsulated and provided
> > instead of duplicated.
>
> I really don't want to maintain a secondary build system on top of CMake
> for doing what CMake does. The main complexities from the module system
> comes from:
>
>   - kits
>   - optional modules
>   - optional depdencies
>
> If it weren't for these 3 things, VTK would be a normal
> `add_subdirectory` CMake project. Exporting the one-time stuff that VTK
> does in its top-level CMakeLists.txt versus the module system is a whole
> different level of abstraction.

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.


> > Building as part of VTK is less of a priority, in my opinion, relative to
> > building externally. However, it does two helpful things 1) these modules
> > get exposed as an optional part of VTK's build configuration, which gives
> > the modules more exposure and makes VTK more exciting and 2) it avoids the
> > work required to set up a Superbuild.
>
> 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.


- Matt