<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 12, 2018 at 7:08 PM Jean-Christophe Fillion-Robin <<a href="mailto:jcfr@kitware.com">jcfr@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"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>> I'm not seeing a rationale</div><div><br></div><div>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:</div><div><br></div><div>- avoid special case, tribal knowledge, ... : a module layout is consistent<br></div><div><br></div><div>- support for packaging independently some part</div><div><br></div><div><br></div><div>@Matt: Could you share your experience within the ITK community ? <br></div><div><br></div></div></div></div></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br></blockquote></div></blockquote><div>We have seen success in the ITK community by maintaining a robust set of common functionality in the core repository and enabling extension modules in other repositories. This provides:</div><div><br></div><div>- Flexibility to mature a module in an incremental process.</div><div>- More contrained core repository build times and distributed builds of other modules.</div><div>- Enhanced backwards compatibility for the core and rapid changes in the peripherary.</div><div>- Enhanced participation from the huge talent pool in the broader FOSS ecosystem.</div><div>- Control and a sense of ownership on individual module repositories.</div><div><br></div><div>If the new module system for VTK improves the extensitibility potential of modules, it will be a big enhancement.</div><div><br></div><div>Ideally, we would have C++XX standard modules and a way to bulid them in place along with One Package Manager To Rule Them All. Since these are currently not available, the ability to share and extend VTK code is a good step. A bonus step forward would allow dependencies between ITK and VTK modules. </div><div><br></div><div><br></div><div>These are all good discussion topics, but to come back to the thread topic, which is important to massively improve VTK's value by enabling integration with other Python packages: thanks to Dave for starting a patch. I wonder we can set a warning / error that BUILD_TESTING has to be disabled when VTK_ENABLE_VTKPYTHON is disabled, change the patch from a WIP, and use VTK_ENABLE_VTKPYTHON=OFF in the VTK Python wheel build. In the future, it would be helpful to have VTK_ENABLE_VTKPYTHON OFF by default and use a provided Python.</div><div><br></div><div>2 cents,</div><div>Matt</div></div></div></div></div></div>