[vtk-developers] module question

[Burlen Loring]

On 11/4/2013 7:55 AM, Marcus D. Hanwell wrote:
> 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
Sounds good.  I'm indeed working to setup a osmesa dashboard, however it 
can run with the default configuration for now.  btw, In recent times 
I've had static linking issues in PV on Cray systems when building 
without X11. I'm suspecting a related issue.

Thanks
Burlen