<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Nov 8, 2018 at 1:53 PM Ben Boeckel <<a href="mailto:ben.boeckel@kitware.com">ben.boeckel@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
`find_package(VTK-prev-stage)` would need to be done in later stages<br>
since multiple packages wouldn't be able to install to the same CMake<br>
package. The installed VTK CMake package would be…not the same for<br>
consumers of the package.<br></blockquote><div><br></div><div>Maybe the VTK build could always divide itself into multiple installed</div><div>cmake packages, to keep things consistent?  I haven't thought this</div><div>through, however, and it might be a very bad idea...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The best thing to do is probably to trim down what constitutes VTK<br>
itself and move modules to external repositories.<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
VTK wouldn't care about the top-level `CMakeLists.txt` at all. It would<br>
find the module via the `vtk.module` file and module logic would just<br>
build it as any other module (this is what ParaView does for its<br>
VTK submodule).<br></blockquote><div><br></div><div>That sounds better than VTK current modules.  I'll have to grab the</div><div>new branch and do some experiments.</div><div><br></div><div>  David</div></div></div>