[vtk-developers] module question

[burlen]

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


On 1/03/2013 09:34 PM, Burlen Loring wrote:
> Hi Marcus,
>> Why are you concerned about it being built if there isn't an onscreen
>> render window?
>> Does vtkRenderingTk do something in its tests, or overrides
>> or other that make you want to add this conditional?
>
> In the case of OSMesa and no X11, the build fails to link because of 
> this module. At first I started in the CMakeLists file excluding 
> classes but then noticed all of the all of the classes in this module 
> are for on screen interaction.  All the tests would then need to be 
> disabled leaving an empty module.  I thought avoiding the module would 
> be better than gutting it completely. 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?
>
> it may not matter at this  point but the condition I used should be 
> reduced to
> if (VTK_USE_X OR VTK_USE_COCOA OR VTK_USE_CARBON)
> since the presence of any of them is sufficient, with or with out OSMesa.
>
> Burlen
>
> On 11/3/2013 2:31 PM, Marcus D. Hanwell wrote:
>> On Sun, Nov 3, 2013 at 5:06 PM, burlen <burlen.loring at gmail.com> wrote:
>>> how can I prevent a module if it depends on a class that won't be 
>>> built? for
>>> eg. vtkRenderingTk contains classes for onscreen use and shouldn't 
>>> be built
>>> if there's no onscreen render window available as in an OSMesa only 
>>> build.
>> Why are you concerned about it being built if there isn't an onscreen
>> render window? Is this a concern for some of the tests, or some other
>> concern?
>>> I encountered this setting VTK_BUILD_ALL_MODULES with OSMesa only. I 
>>> see
>>> that there's an EXCLUDE_FROM_ALL flag, however that would reduce the 
>>> testing
>>> coverage of these classes, so I wanted to see if there was a way to 
>>> make the
>>> module conditional.
>> EXCLUDE_FROM_ALL is a little arbitrary, but it effectively excludes
>> some modules when enable all modules is activated for modules with
>> unusual/difficult dependencies. It should be used very sparingly, we
>> actually want to have as few modules as possible excluded but this is
>> a useful convenience for setting up dashboards that want to test as
>> many things possible. Perhaps we should have a "really, enable EVERY
>> possible module"...
>>> I'm tempted to do this:
>>>
>>> # Rendering/Tk/module.cmake
>>> if (NOT VTK_OPENGL_HAS_OSMESA OR (VTK_USE_X OR VTK_USE_COCOA OR
>>> VTK_USE_CARBON))
>>>    vtk_module(vtkRenderingTk
>>>      GROUPS
>>>        Tk
>>>      DEPENDS
>>>        vtkRenderingOpenGL
>>>        vtkInteractionStyle
>>>        vtkInteractionImage
>>>      COMPILE_DEPENDS
>>>        vtkTclTk
>>>      TEST_DEPENDS
>>>        vtkRenderingVolume
>>>      EXCLUDE_FROM_WRAPPING
>>>      )
>>> endif()
>>>
>>> I doubt that's going to fly. is there a better solution?
>> One of the core goals of modularization was to reduce the arbitrary
>> changes in libraries, linking, API and other things based on build
>> settings. Does vtkRenderingTk do something in its tests, or overrides
>> or other that make you want to add this conditional?
>>
>> Thanks,
>>
>> Marcus
>