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

Jean-Christophe Fillion-Robin jcfr at kitware.com
Tue Dec 11 18:08:12 EST 2018


> it'd be better to just set PYTHONPATH on the test suite and use a
standard Python executable.

+1


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

if(NOT VTK_SOURCE_DIR)
  // find method 1
else()
  // find method 2
endif()



1. Looking at the "new-cmake-module" branch, are the "vtkLocal" and "vtkMy"
examples up-to-date ?

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 ?

3. To test the updated build system with Slicer, would it be possible to
rebase the branch "new-cmake-module" ?

Thanks
Jc





On Mon, Dec 10, 2018 at 10:07 AM Ben Boeckel <ben.boeckel at kitware.com>
wrote:

> On Fri, Dec 07, 2018 at 17:00:20 -0500, Jean-Christophe Fillion-Robin
> wrote:
> > > distribution builds should try to enable *everything*
> >
> > In that context, I don't think it makes sense to build VTK own python
> > interpreter. Ideally, it should be possible to run VTK test with or
> without
> > it.
>
> Yes, it is very odd that we've always built our own interpreter. IMO,
> it'd be better to just set PYTHONPATH on the test suite and use a
> standard Python executable.
>
> > I also envision we could have a "vtk-openvr" python module but it
> wouldn't
> > be available by default when installing vtk wheel. To support this level
> of
> > "modularity" , we would continue building part of VTK independently (for
> > example, we can already do this with the VTKOpenVR module)
>
> The new module system doesn't support this at the moment (i.e., the
> `find_package(VTK)` code has been ripped out of the OpenVR module). The
> problem with this is that if a module can be built inside and outside of
> VTK, dependent projects cannot know whether to do `find_package(VTK
> COMPONENTS RenderingOpenVR)` or `find_package(VTKOpenVR)`.
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20181211/78adbb72/attachment.html>


More information about the vtk-developers mailing list