<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>>> module can be built inside and outside of VTK<br></div><div>> But the better question is "should we?".</div><div><br></div><div>Generally speaking yes, supporting the composition of CMake projects by both (1) "aggregation" (add_subdirectory) and (2) "finding dependency" is important.</div><div><br></div><div>This applies to first class modules (e.g VTK module, ITK module, ... ) and also third-party project (e.g zlib, hdf5, ...)<br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div>> 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)`.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>> Would this outside-VTK build expect to put its Python module under `vtkmodules` still?</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><br></div>>> <span class="gmail-im"> Are the functions vtk_module_add_module, vtk_module_link, ... designed to be used outside of VTK build tree ?</span></div><div dir="ltr"><span class="gmail-im"><br></span></div><div dir="ltr"><span class="gmail-im">> Yes. VTK has no special inside-variable control over the code. Everything is passed in via parameters to the functions<br></span></div><div dir="ltr"><span class="gmail-im"><br></span></div><div><span class="gmail-im">This is great. This means that these functions could be used inside and outside VTK.<br></span></div><div><span class="gmail-im"><br></span></div>> I've just rebased it today actually</div><div dir="ltr"><br><div><span class="gmail-im">Great.</span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">> Does Slicer make VTK modules itself or just consume them?<br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">Almost both.<br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im"><span class="gmail-im">Consume them: yes<br></span></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im">For the "make VTK modules", there are few cases:</span></div><div><span class="gmail-im">- reuse of VTK wrapping infrastructure through <a href="https://github.com/Slicer/Slicer/blob/master/CMake/vtkMacroKitPythonWrap.cmake">Slicer/CMake/vtkMacroKitPythonWrap.cmake</a><br></span></div><div><span class="gmail-im"><span class="gmail-im">- 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.</span></span></div><div><span class="gmail-im">- building of VTK/Rendering/OpenVR into a Slicer extension. <br></span></div><div><span class="gmail-im"><br></span></div><div><span class="gmail-im"><br></span></div><div dir="ltr"><div><br></div><div><br></div><div><br></div><div><br><span class="gmail-im"></span></div><div><span class="gmail-im"></span></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 6:55 PM 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 Tue, Dec 11, 2018 at 18:08:12 -0500, Jean-Christophe Fillion-Robin wrote:<br>
> > The new module system doesn't support this at the moment [...] The<br>
> > problem with this is that if a module can be built inside and outside of VTK<br>
> <br>
> I see. That shouldn't be a problem, we can always do the following:<br>
<br>
You trimmed the important part of that. It isn't impossible. But the<br>
better question is "should we?".<br>
<br>
> if(NOT VTK_SOURCE_DIR)<br>
> // find method 1<br>
> else()<br>
> // find method 2<br>
> endif()<br>
<br>
The thing is that the module is incompatible from a consumer point of<br>
view in the two builds. One makes `VTK::RenderingOpenVR` and is provided<br>
via `find_package(VTK COMPONENTS RenderingOpenVR)`. The other…isn't.<br>
IMO, if the module can't be built as part of VTK often enough to be<br>
expected in a VTK build (e.g., pip or a Linux package), then it should<br>
just be in a separate repository.<br>
<br>
Also, the amount of code in that first one is not trivial:<br>
<br>
find_package(VTK COMPONENTS CommonCore IOImage ...)<br>
vtk_module_scan(...)<br>
vtk_module_build(...)<br>
vtk_module_wrap_python(...)<br>
<br>
and that still isn't going to work because it will need to detect when<br>
the module system is including the CMakeLists.txt file (or it just needs<br>
to be a separate directory completely). Would this outside-VTK build<br>
expect to put its Python module under `vtkmodules` still? Either way, I<br>
really don't want modules doing this kind of stuff. Either it's part of<br>
VTK or it isn't.<br>
<br>
> 1. Looking at the "new-cmake-module" branch, are the "vtkLocal" and "vtkMy"<br>
> examples up-to-date ?<br>
<br>
I haven't looked at them yet. Other examples have been updated though.<br>
<br>
> <a href="https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkLocal/CMakeLists.txt" rel="noreferrer" target="_blank">https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkLocal/CMakeLists.txt</a><br>
> <a href="https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkMy/CMakeLists.txt" rel="noreferrer" target="_blank">https://gitlab.kitware.com/ben.boeckel/vtk/blob/new-cmake-module/Examples/Build/vtkMy/CMakeLists.txt</a><br>
> <br>
> 2. Are the functions vtk_module_add_module, vtk_module_link, ... designed<br>
> to be used outside of VTK build tree ?<br>
<br>
Yes. VTK has no special inside-variable control over the code.<br>
Everything is passed in via parameters to the functions, so VTK's<br>
install directory variables are just parameters to this function. I'd<br>
like to keep it that way.<br>
<br>
> 3. To test the updated build system with Slicer, would it be possible to<br>
> rebase the branch "new-cmake-module" ?<br>
<br>
I've just rebased it today actually (for a ParaView rebase). Does Slicer<br>
make VTK modules itself or just consume them?<br>
<br>
--Ben<br>
</blockquote></div>