<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>> it'd be better to just set PYTHONPATH on the test suite and use a standard Python executable.<span class="gmail-im"><br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">+1<br></span></div><div><br></div><div><br></div><div>>  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</div><div><br></div><div>I see. That shouldn't be a problem, we can always do the following:</div><div><br></div><div>if(NOT VTK_SOURCE_DIR)</div><div>  // find method 1</div><div>else()</div><div>  // find method 2<br></div><div>endif()<br></div><div><br></div><div><br></div><div><br></div><div>1. Looking at the "new-cmake-module" branch, are the "vtkLocal" and "vtkMy" examples up-to-date ?</div><div><br></div><div><div><a href="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/vtkLocal/CMakeLists.txt</a></div><div><a href="https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkMy/CMakeLists.txt">https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkMy/CMakeLists.txt</a></div><div><br></div><div>2. Are the functions vtk_module_add_module, vtk_module_link, ... designed to be used outside of VTK build tree ? <br></div></div><div><br></div><div>3. To test the updated build system with Slicer, would it be possible to rebase the branch "new-cmake-module" ?<br></div><div><br></div><div>Thanks</div><div>Jc<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 10, 2018 at 10:07 AM Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com">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 Fri, Dec 07, 2018 at 17:00:20 -0500, Jean-Christophe Fillion-Robin wrote:<br>
> > distribution builds should try to enable *everything*<br>
> <br>
> In that context, I don't think it makes sense to build VTK own python<br>
> interpreter. Ideally, it should be possible to run VTK test with or without<br>
> it.<br>
<br>
Yes, it is very odd that we've always built our own interpreter. IMO,<br>
it'd be better to just set PYTHONPATH on the test suite and use a<br>
standard Python executable.<br>
<br>
> I also envision we could have a "vtk-openvr" python module but it wouldn't<br>
> be available by default when installing vtk wheel. To support this level of<br>
> "modularity" , we would continue building part of VTK independently (for<br>
> example, we can already do this with the VTKOpenVR module)<br>
<br>
The new module system doesn't support this at the moment (i.e., the<br>
`find_package(VTK)` code has been ripped out of the OpenVR module). The<br>
problem with this is that if a module can be built inside and outside of<br>
VTK, dependent projects cannot know whether to do `find_package(VTK<br>
COMPONENTS RenderingOpenVR)` or `find_package(VTKOpenVR)`.<br>
<br>
--Ben<br>
</blockquote></div>