[vtk-developers] vtk_module_autoinit in new module system

Elvis Stansvik elvis.stansvik at orexplore.com
Tue Jan 22 13:05:13 EST 2019


Den tis 22 jan. 2019 kl 18:36 skrev Ben Boeckel <ben.boeckel at kitware.com>:
>
> On Tue, Jan 22, 2019 at 18:15:54 +0100, Elvis Stansvik wrote:
> > I don't exactly understand, but I'm by no means a cmake guru, but couldn't
> > the required -D flags be passed through the target interface definitions of
> > the targets that VTK exports, then I could get them through just
> > target_link_libraries(stuff I need)?
>
> Brad and I had discussions about this, but no. Let's take
> `vtkRenderingCore` as an example. First, you need to know what other
> targets the consuming target uses (not possible with generator
> expressions). Once you have that list, you need to filter down which
> ones `IMPLEMENT vtkRenderingCore`, count them and join their library
> names using `,`. This results in something like this:
>
>     #define vtkRenderingCore_AUTOINIT 2(vtkRenderingOpenGL2,vtkRenderingFoobar)
>
> This then is written to a file since MSVC doesn't support commas (or
> parentheses; I forget which) on the command line. The resulting
> generated `-D` flag is:
>
>     -DvtkRenderingCore_AUTOINIT_INCLUDE=\".../vtkModuleAutoInit_${hash}.h\"
>
> where `${hash}` is the MD5 of the set of modules being linked (to avoid
> collisions when linking multiple times).

Ah, now I see what kludge this would be. Thanks for clarifying.

I never really thought of how those defines were structured, it "just worked".

>
> The old module system just gave you everything possible for all usages
> via `VTK_DEFINITIONS`. Now, you get exactly what is necessary, nothing
> more.
>
> > Just hoping there's some way of getting rid of the double bookkeeping since
> > it feels like a step back maintenancewise from a user pov if I have to
> > remember to do this.
>
> I agree that it is less handy, but there's not much to be done with
> CMake features available today.

Fair enough.

Elvis

>
> --Ben


More information about the vtk-developers mailing list