[vtk-developers] New module system preview

[Elvis Stansvik]

Fantastic work Ben. One question below.

Den mån 29 okt. 2018 17:07Ben Boeckel <ben.boeckel at kitware.com> skrev:

> Hi all,
>
> I've gotten the new module system to a point that I'd like to open up
> testing to other developers. It's not 100% complete (see the known
> issues listing below), but it's pretty close. I'd highly recommend using
> a new build tree for building the branch.
>
> Notes for WIP things on the branch:
>
>   - There's a hard-coded list of "don't build this" in CMakeLists.txt
>     currently just for my convenience. Feel free to edit the
>     `REJECT_MODULES` argument list as needed for your machine(s).
>
> Overview of changes:
>
>   - Instead of `module.cmake`, there are `vtk.module` and `vtk.kit`
>     files. These are basically CMake argument lists, but no variable
>     expansion is allowed. If there are optional dependencies, they must
>     be private dependencies. Optional public dependencies indicate that
>     a new module should be made instead.
>
>   - Modules may now be "rejected" and never built. This turns off
>     *dependent* modules. If a module is required and also has a rejected
>     module as a dependency, an error occurs.
>
>   - Minimum CMake is still 3.3, but kit support requires CMake 3.12+ for
>     object library features.
>
>   - There are no more `vtk_mpi_link` or `vtk_opengl_link` "magic"
>     functions. Instead, just depend on the `VTK::mpi` and `VTK::opengl`
>     modules.
>
>   - Third party modules now declare whether they support external copies
>     or not (i.e., no more useless `VTK_USE_SYSTEM_kwsys` variable). See
>     the `ThirdParty` directory for various examples. Other third parties
>     only support external copies (e.g., `VTK::mpi` and `VTK::opengl`).
>
>   - Imported targets are now preferred for `find_package` callers. Third
>     party packages warn about this usage, but others do not. There is
>     also the `vtk_module_find_package` call which also adds required
>     `find_package` calls to the `vtk-config.cmake` file for external
>     consumers (only necessary when using imported targets).
>
>   - Module names now look like `VTK::CommonCore`. This is a target name
>     which can be used anywhere, within or outside of the VTK source
>     tree. Non-module projects now do:
>
> ```cmake
> # Find VTK.
> find_package(VTK REQUIRED COMPONENTS CommonCore)
> # Make two programs.
> add_executable(myexe1 myexe1.c)
> add_executable(myexe2 myexe2.c)
> # Add include directories, link line, compile definitions, etc.
> # necessary to use VTK::CommonCore.
> target_link_libraries(myexe1 PRIVATE VTK::CommonCore)
> target_link_libraries(myexe2 PRIVATE VTK::CommonCore)
> # Add VTK_AUTOINIT defines to the targets.
> vtk_module_autoinit(TARGETS myexe1 myexe2 MODULES VTK::CommonCore)
>

Can this not be brought in automatically via the target's interface
definitions?

With the current setup, I'm getting them via ${VTK_DEFINITIONS} I think.

Would be nice to avoid the repeated target name.

Elvis

```
>
>   - To add requirements to a module, the module system offers some
>     functions in lieu of CMake's `target_*`. This is in order to
>     properly support kits (the `CommonCore` target is just an
>     `INTERFACE` library in this case and `PRIVATE` link libraries need
>     copied onto the containing kit). The functions:
>     * `vtk_module_compile_options`
>     * `vtk_module_definitions`
>     * `vtk_module_include`
>     * `vtk_module_link`
>     * `vtk_module_link_options` (depends on `target_link_options` in
>       CMake 3.13+)
>
> It is currently based on `master` as of a week ago, but I'll probably
> rebase again this week.
>
> Please file issues found with the branch on my fork of VTK:
>
>     https://gitlab.kitware.com/ben.boeckel/vtk/issues
>
> to make things easier to track. Since Gitlab doesn't support MRs between
> sibling forks (yet), please attach patches to issues if you have a fix.
>
> Known issues:
>
>   - Running generated Java wrappers needs some attention. Missing
>     symbols (from Java code?) happen when running the tests.
>   - Windows support (there are some `:` characters left in filenames
>     yet).
>
> Unimplemented:
>
>   - Remote modules (conceptually the same as before, but there are no
>     remote modules that have been ported right now)
>   - `OPTIONAL_PYTHON_LINK` magic keyword. This can now just be supported
>     in the `VTK::Python` module, but has not been implemented.
>
> Untested:
>
>   - Multi-config generators (e.g., Xcode and Visual Studio).
>   - Mobile device support.
>
> Thanks,
>
> --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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://public.kitware.com/pipermail/vtk-developers/attachments/20181029/95776f8e/attachment-0001.html>