[vtk-developers] module question

Marcus D. Hanwell marcus.hanwell at kitware.com
Mon Nov 4 10:55:25 EST 2013


On Mon, Nov 4, 2013 at 10:29 AM, burlen <burlen.loring at gmail.com> wrote:
>> Although now I'm starting to wonder if it might be better to do away with
>> this module and put the classes and tests under RenderingOpenGL?
>
> I'm going to back away from that :-) less modular would be a step in the
> wrong direction. although, maybe the Rendering/Tk module should be moved to
> GUISupport/TK, and live with the other GUI stuff.
>
> the main issue is that the build fails with, VTK_BUILD_ALL_MODULES=ON ,
> VTK_USE_X=OFF, VTK_OPENGL_HAS_OSMESA=ON.
> the combination of VTK_USE_X=OFF , VTK_OPENGL_HAS_OSMESA=ON should probaly
> imply none of the  GUI related modules gets built.
>
> When a module is requested but can't be built could could it be skipped by a
> conditional in its module.cmake? or could a conditional in its CMakeList
> leave it empty? should the build just fail? or something else?
>
I see what you mean now, do you mind if I dig into this a little? The
VTK_USE_* options are decidedly non-modular, but were necessary due to
the very tight coupling in some of the rendering classes that would
have taken more time than we had available to pull apart.

The vtkRenderingOpenGL module is the least modular, having several
compile-time build options that change it significantly. Anything that
is tightly coupled to it will suffer with similar issues, having a set
of failing options gives me a good starting point. The
VTK_BUILD_ALL_MODULES=ON is there largely as a convenience for
dashboards though - the option groups should be used in general.

Marcus



More information about the vtk-developers mailing list