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

[Jean-Christophe Fillion-Robin]

>> module can be built inside and outside of VTK
> But the better question is "should we?".

Generally speaking yes, supporting the composition of CMake projects by
both (1) "aggregation" (add_subdirectory)  and (2) "finding dependency" is
important.

This applies to first class modules (e.g VTK module, ITK module, ... ) and
also third-party project (e.g zlib, hdf5, ...)

Also, by having no differences between the build system of "module or
project" that can be either be aggregated or built as dependency, it is
easy to maintain and communicate a set of best practices, streamline use of
projects in various scenarios without having to maintain forks.



> The thing is that the module is incompatible from a consumer point of
view in the two builds. One makes `VTK::RenderingOpenVR` and is provided
via `find_package(VTK COMPONENTS RenderingOpenVR)`.

I think this is something that we probably need to address in CMake. In the
mean time, we could have a "vtk_ns" and vtk_ns_colon variables and
reference target with "${vtk_ns_colon}RenderingOpenVR". Also wondering if
introducing some new genex could also help.


> Would this outside-VTK build expect to put its Python module under
`vtkmodules` still?

Good question. When building wheels, the answer is yes. That way, the
content of all "VTK" wheels would end up in the same folder "vtkmodules"
and shared library are in the same directory. Installing/uninstalling
wheels also work well because pip has a manifest and only removes the files
it needs to.




>> Are the functions vtk_module_add_module, vtk_module_link, ... designed
to be used outside of VTK build tree ?

> Yes. VTK has no special inside-variable control over the code. Everything
is passed in via parameters to the functions

This is great. This means that these functions could be used inside and
outside VTK.

> I've just rebased it today actually

Great.


> Does Slicer make VTK modules itself or just consume them?

Almost both.

Consume them: yes

For the "make VTK modules", there are few cases:
- reuse of VTK wrapping infrastructure through
Slicer/CMake/vtkMacroKitPythonWrap.cmake
<https://github.com/Slicer/Slicer/blob/master/CMake/vtkMacroKitPythonWrap.cmake>
- we have a lot of "pure" VTK library that currently use their own build
system. In the future, it would be nice to standardize on reusing VTK build
system.
- building of VTK/Rendering/OpenVR into a Slicer extension.







On Tue, Dec 11, 2018 at 6:55 PM Ben Boeckel <ben.boeckel at kitware.com> wrote:

> On Tue, Dec 11, 2018 at 18:08:12 -0500, Jean-Christophe Fillion-Robin
> wrote:
> > > The new module system doesn't support this at the moment [...] The
> > > problem with this is that if a module can be built inside and outside
> of VTK
> >
> > I see. That shouldn't be a problem, we can always do the following:
>
> You trimmed the important part of that. It isn't impossible. But the
> better question is "should we?".
>
> > if(NOT VTK_SOURCE_DIR)
> >   // find method 1
> > else()
> >   // find method 2
> > endif()
>
> The thing is that the module is incompatible from a consumer point of
> view in the two builds. One makes `VTK::RenderingOpenVR` and is provided
> via `find_package(VTK COMPONENTS RenderingOpenVR)`. The other…isn't.
> IMO, if the module can't be built as part of VTK often enough to be
> expected in a VTK build (e.g., pip or a Linux package), then it should
> just be in a separate repository.
>
> Also, the amount of code in that first one is not trivial:
>
>     find_package(VTK COMPONENTS CommonCore IOImage ...)
>     vtk_module_scan(...)
>     vtk_module_build(...)
>     vtk_module_wrap_python(...)
>
> and that still isn't going to work because it will need to detect when
> the module system is including the CMakeLists.txt file (or it just needs
> to be a separate directory completely). Would this outside-VTK build
> expect to put its Python module under `vtkmodules` still? Either way, I
> really don't want modules doing this kind of stuff. Either it's part of
> VTK or it isn't.
>
> > 1. Looking at the "new-cmake-module" branch, are the "vtkLocal" and
> "vtkMy"
> > examples up-to-date ?
>
> I haven't looked at them yet. Other examples have been updated though.
>
> >
> https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkLocal/CMakeLists.txt
> >
> https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkMy/CMakeLists.txt
> >
> > 2. Are the functions vtk_module_add_module, vtk_module_link, ... designed
> > to be used outside of VTK build tree ?
>
> Yes. VTK has no special inside-variable control over the code.
> Everything is passed in via parameters to the functions, so VTK's
> install directory variables are just parameters to this function. I'd
> like to keep it that way.
>
> > 3. To test the updated build system with Slicer, would it be possible to
> > rebase the branch "new-cmake-module" ?
>
> I've just rebased it today actually (for a ParaView rebase). Does Slicer
> make VTK modules itself or just consume them?
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20181212/0b48f59e/attachment.html>