[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