[vtk-developers] New module system preview

[Elvis Stansvik]

Den mån 29 okt. 2018 kl 21:42 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Mon, Oct 29, 2018 at 15:45:36 -0400, David Thompson wrote:
> > Even if it is two passes, why can't it be done from CMakeLists.txt?
> > The second pass just adds library dependencies, header search paths,
> > other target properties, and install rules, correct? Can't that be
> > done any time after the libraries are declared?
>
> First, the concept would require `target_link_libraries` support for
> out-of-directory targets. That can't be done without 3.13.0 (still in
> its rc cycle). It also means that we wouldn't be able to say "no" to
> building some modules without somehow "undo"ing an `add_library` call.
>
> Second, it's an ease-of-use problem. Say I don't have MPI on my machine.
> I can't `add_subdirectory` *any* directory which requires `VTK::mpi`
> because that module can't exist on my machine. How is the module system
> supposed to know what directories can and cannot be included? If it is
> `CMakeLists.txt` via `add_subdirectory` or `include`, the structure
> would end up like:
>
> ```cmake
> if (vtk_module_phase STREQUAL "scan")
>   vtk_module_declare(<vtk.module args>)
> elseif (vtk_module_phase STREQUAL "build")
>   vtk_module_add_module(...)
> endif ()
> ```
>
> Third, part of the point of `vtk.module` is so that there *is no logic*
> allowed. Making it part of `CMakeLists.txt` makes it much harder to
> enforce this. Though this does make me think that we could stuff the
> `vtk.module` contents in a comment header of the associated
> `CMakeLists.txt`. That might be worth looking into. I'll add a TODO item
> for it.

Let me just jump in and say that while it sounds neat to embed it
comments, it might make it slightly harder to make an updated version
of Utilities/Maintenance/WhatModulesVTK.py script (which I love!).

I kind of like the VTK system with these separate files. Even if it's
a bit unorthodox, they're very concise descriptions of the modules. I
like how I can do find . -name module.cmake to find all modules, or
cat Some/Dir/module.cmake to get info about a module. It's very
inspectable using standard tools.

It's just my 2 cents though, so take it or leave it :)

Elvis

>
> Towards the third point, it was a mistake to allow
> `${VTK_RENDERING_BACKEND}` in the old module system's `module.cmake`
> files. VTK should have supported building OpenGL1 *and* OpenGL2 backends
> at the same time with executables using the object factory mechanism to
> decide which one gets used. It also meant that some modules had classes
> popping in and out of existence depending on other flags (e.g.,
> `vtkIOMovie` contains `vtkOggTheoraWriter` depending on whether or not
> `vtkoggtheora` is available…not something easy to have Just Work via
> `find_package(VTK)` failing (the new module system now has a
> `VTK::IOOggTheora` module for this class).
>
> > It just feels like VTK and ParaView should be "best practices"
> > examples. Your branch gets things a *lot* closer, but some twiddly
> > details (the special .module/.kit files, no use of add_subdirectory,
> > etc) get in the way of someone familiar with CMake but not these
> > projects.
>
> Unfortunately, things like kits, optional component building, complex
> dependency graphs, etc. are not "common" and doing them via "best
> practices" applicable to CMake projects in general isn't easy.
>
> IMO, "best practices" would tell me that VTK should be many repositories
> (or, many top-level builds at least) and each build has *no options* to
> turn on or off bits of the build (modulo platform support and
> deprecation). If one wants MPI support, go build the MPI subdirectory
> and you get VTK MPI support.
>
> Granted, there might be a top-level "enable these sections of code" flag
> which runs all the subprojects like a superbuild, but I don't think the
> downsides of the superbuild (i.e., ExternalProject) are ignorable for
> projects with a developer and user community the size of VTK as-is.
>
> --Ben
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://public.kitware.com/mailman/listinfo/vtk-developers
>