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

[Matt McCormick]

On Thu, Dec 13, 2018 at 11:50 AM Ben Boeckel <ben.boeckel at kitware.com>
wrote:

> On Wed, Dec 12, 2018 at 19:08:30 -0500, Jean-Christophe Fillion-Robin
> wrote:
> > > I'm not seeing a rationale
> >
> > By ensuring the build system of a VTK/ITK/Slicer... modules is the same
> if
> > it is built inside or outside the "main" application/libraries allows the
> > following:
>
> It *cannot* be the same. `find_package(VTK)` only contains the
> information VTK had at the time of *its* build. Modules built outside of
> it won't show up. If a module is part of VTK, VTK does lots of heavy
> lifting one-time-setup things. Install directories, minimum CMake
> version, CMake policies, etc. Any standalone module will have to copy
> that information. I suspect that's at least 100 lines of CMake code
> (some of which can't be abstracted out).
>
> > - avoid special case, tribal knowledge, ... : a module layout is
> consistent
>
> This support itself is a special case itself AFAICS. Module layouts are
> consistent right now. Modules which do this are going to be the
> different ones.
>
> > - support for packaging independently some part
>
> That's just more code that modules will have to duplicate from VTK.
>

The suggested duplication is not necessary.

To implement, on a high level:

- Required CMake settings are stored in VTKConfig.cmake
- There is a VTKTargets.cmake that contains all the target information from
the main build.
- <module>Targets.cmake contains module target information. This is kept in
an "index" (a certain folder relative to VTKConfig.cmake) that is searched
and loaded by VTKConfig.cmake

The module contains minimal CMake setup, but that is required for any
project that depends on VTK.



> > @Matt: Could you share your experience within the ITK community ?
>
> <Matt's reply>
>
> This seems more like remote modules as a path for migrating *into* VTK.
> Building OpenVR separately is like moving it *out* of VTK. *That* is
> what I don't understand.
>
> It is not possible or desirable for everything to move into VTK. On one
side, the barrier to entry into VTK is high, and and on the other side,
centralized maintenance cannot sustainably maintain everything under the
sun. Distributed development of domain specific, etc., modules will be
helpful.

OpenVR, for example, requires special hardware and software to test.
Separate development and testing enables folks to set up independent
testing on configuration that satisfy its dependencies.

- Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20181213/75606c41/attachment.html>