[vtk-developers] Slight behavioral change in WhatModulesVTK.py (new module system)?

Elvis Stansvik elvis.stansvik at orexplore.com
Fri Jan 11 12:24:54 EST 2019


Alright, thanks for clarifying Ben. I do believe we are directly including
headers though, at least for the vtkFreeTypeFontConfig case. But I'll
double check.

Otherwise I'll just add these manually (keeping the magic knowledge in my
head :)).

The future enhancement you mentioned sounds like a fun project. Perhaps
CMake server mode can be leveraged?

Elvis

Den fre 11 jan. 2019 17:47Ben Boeckel <ben.boeckel at kitware.com> skrev:

> On Fri, Jan 11, 2019 at 17:41:09 +0100, Elvis Stansvik wrote:
> > Nothing surprising, except:
> >
> >   vtkRenderingFreeTypeFontConfig
> >   vtkRenderingVolumeOpenGL2
> >
> > These are present before, but has no corresponding lines after the
> > merge. We make use of both.
> >
> > Any ideas Ben? Is this expected or is there something fishy here.
>
> If the headers are not included explicitly, the script will miss it. I
> think the right way to do this would be to collect `IMPLEMENTABLE` and
> `IMPLEMENTS` bits and warn that modules which have object factories may
> be missing implementations (with hints as which modules implement each
> module with).
>
> There had been "magical" knowledge embedded in the script that I removed
> in commit 9437f76db782c48ebaae303c0e2f472147a3e712.
>
> Another (future) enhancement would be to have it work with an installed
> VTK (or any other VTK-module providing package really) rather than
> forcing a VTK source tree to be present. It also wouldn't hint modules
> which were not built. This is a much harder problem since it would need
> to parse and understand CMake code.
>
> --Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190111/29c3a119/attachment.html>


More information about the vtk-developers mailing list