<div dir="ltr"><br><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 13, 2018 at 1:48 PM Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com" target="_blank">ben.boeckel@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Dec 13, 2018 at 13:16:40 -0500, Matt McCormick wrote:<br>
> - Required CMake settings are stored in VTKConfig.cmake<br>
<br>
VTK's new vtk-config.cmake, right now exports this set of variables:<br>
<br>
  VTK_VERSION VTK_LEGACY_REMOVE VTK_HAS_VTKm VTK_OPENGL_HAS_EGL<br>
  VTK_WRAP_PYTHON VTK_WRAP_JAVE VTK_PYTHONPATH VTK_LIBRARIES<br>
<br>
And variables which don't make sense aren't set at all (e.g.,<br>
VTK_OPENGL_HAS_EGL is only set if the VTK::opengl module has been<br>
built and VTK_PYTHONPATH is only set if Python wrapping has been<br>
enabled). VTK_LIBRARIES is just the list of targets from COMPONENTS and<br>
OPTIONAL_COMPONENTS that have been requested. If no components are<br>
requested, VTK_LIBRARIES is empty.<br>
<br>
No other variables are required to use VTK from CMake, so they aren't<br>
provided.<br></blockquote><div><br></div><div>Thanks for the explanation.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> - There is a VTKTargets.cmake that contains all the target information from<br>
> the main build.<br>
<br>
Eh, there's more than that now because CMake only exports properties it<br>
deems as important. Other sidecar files exist too.<br>
<br></blockquote><div>Yes. And, as discussed below, there is an additional need for calling the "find_dependency" macro as discussed below...</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> - <module>Targets.cmake contains module target information. This is kept in<br>
> an "index" (a certain folder relative to VTKConfig.cmake) that is searched<br>
> and loaded by VTKConfig.cmake<br>
<br>
vtk-config.cmake doesn't support dropping things in here. The new module<br>
system has this:<br>
<br>
  VTK-targets.cmake<br>
  VTK-vtk-module-properties.cmake<br>
  VTK-vtk-module-find-packages.cmake (uses components to only find what<br>
  was requested)<br>
  VTK-vtk-python-module-properties.cmake (if Python wrapping is enabled)<br>
<br>
The old module system globbing for this information has historically not<br>
worked out well. I don't want to continue that mistake. Concretely, in<br>
an install of ParaView, `find_package(VTK)` didn't work because ParaView<br>
modules were included in VTK's glob and assumed variables were set that<br>
only ParaView's config provided. This errored out and made it impossible<br>
to use without setting a magic ParaView variable before finding VTK.</blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I<br>
really don't want people to say "find VTK doesn't work" because some<br>
other project dropped a broken CMake file in its CMake configuration<br>
directory.<br></blockquote><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The module contains minimal CMake setup, but that is required for any<br>
> project that depends on VTK.<br>
<br>
Yes, that is not "a few lines". It involves finding VTK, scanning<br>
modules, making sure that the found VTK provides the required modules,<br>
building modules, optionally wrapping, installing CMake configuration<br>
files, etc. And that doesn't include packaging. </blockquote><div><br></div><div>CMake functions to do all these things could be encapsulated and provided instead of duplicated.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> > > @Matt: Could you share your experience within the ITK community ?<br>
> ><br>
> > <Matt's reply><br>
> ><br>
> > This seems more like remote modules as a path for migrating *into* VTK.<br>
> > Building OpenVR separately is like moving it *out* of VTK. *That* is<br>
> > what I don't understand.<br>
> ><br>
> It is not possible or desirable for everything to move into VTK. On one<br>
> side, the barrier to entry into VTK is high, and and on the other side,<br>
> centralized maintenance cannot sustainably maintain everything under the<br>
> sun. Distributed development of domain specific, etc., modules will be<br>
> helpful.<br>
<br>
Agreed. My follow-up: why do they have to support being built *as part<br>
of VTK* then? Why is `find_package(VTK)` not sufficient as the *only*<br>
way to build these projects like with every other dependency? I know the<br>
existing module system wrapping and such wasn't nice outside of VTK, but<br>
that is now fixed.<br>
<br></blockquote><div>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.</div><div> </div></div></div>