vtk_module_autoinit in new module system

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

vtk_module_autoinit in new module system

Bill Lorensen
Ben,

I'm curious why with the new module system we need to add
vtk_module_autoinit for the targets in the new system.

I never used it in the old system.'

Bill

--
Unpaid intern in BillsParadise at noware dot com
_______________________________________________
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://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk_module_autoinit in new module system

VTK - Dev mailing list
On Fri, Jan 18, 2019 at 14:11:21 -0800, Bill Lorensen wrote:
> I'm curious why with the new module system we need to add
> vtk_module_autoinit for the targets in the new system.
>
> I never used it in the old system.'

That's because `VTK_DEFINITIONS` had the entries after `find_package`
based on the passed-in components. The new module system instead prefers
to attach the required definition (and header file generation) to
exactly which targets need them.

--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://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk_module_autoinit in new module system

Elvis Stansvik
Den tis 22 jan. 2019 16:31Ben Boeckel via vtk-developers <[hidden email]> skrev:
On Fri, Jan 18, 2019 at 14:11:21 -0800, Bill Lorensen wrote:
> I'm curious why with the new module system we need to add
> vtk_module_autoinit for the targets in the new system.
>
> I never used it in the old system.'

That's because `VTK_DEFINITIONS` had the entries after `find_package`
based on the passed-in components. The new module system instead prefers
to attach the required definition (and header file generation) to
exactly which targets need them.

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)?

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.

Elvis


--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://vtk.org/mailman/listinfo/vtk-developers


_______________________________________________
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://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk_module_autoinit in new module system

VTK - Dev mailing list
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).

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.

--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://vtk.org/mailman/listinfo/vtk-developers

Reply | Threaded
Open this post in threaded view
|

Re: vtk_module_autoinit in new module system

Elvis Stansvik
Den tis 22 jan. 2019 kl 18:36 skrev Ben Boeckel <[hidden email]>:

>
> 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
_______________________________________________
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://vtk.org/mailman/listinfo/vtk-developers