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

[Ben Boeckel]

On Thu, Dec 13, 2018 at 15:42:49 -0500, Matt McCormick wrote:
> > Eh, there's more than that now because CMake only exports properties it
> > deems as important. Other sidecar files exist too.
> >
> Yes. And, as discussed below, there is an additional need for calling the
> "find_dependency" macro as discussed below...

No? VTK manages its modules including transitive dependencies. That is
hard enough to manage without other projects wanting to jump on the
bandwagon.

> > 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).

> 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.

> > 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.

> 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.

--Ben