[Paraview-developers] wrapping cmake dependency issue?

[Burlen Loring]

Hi Ben,

It's nice that you are looking into it. Sounds like maybe you got some 
useful insight. I'm not sure changing the backend to GL2 is the best way 
to get at the issue. In that case you are using different classes, with 
different api, and hence a lot of stuff should be recompiled and 
re-wrapped. Wouldn't it be straight forward and give you better insight 
to look at what happens when you change the OpenGL install?

Burlen

On 04/20/2015 11:18 AM, Ben Boeckel wrote:
> On Thu, Feb 26, 2015 at 11:01:28 -0800, Burlen Loring wrote:
>> This is in regard to what to me seems like a bug in dependency chain of
>> the CS and Python wrapping.  Yesterday I was debugging a segv on 4.3.1
>> build on our Cray and I had to test a different a different OpenGL
>> build. So I opened up the CMakeCache of my build and changed the one
>> variable- namely the one specifying the OpenGL library. This should have
>> resulted in the executables and a few of the libs re-linking, however in
>> addition all of the CS and Python wrapping was regenerated and those
>> files recompiled and re linked. As a result what should have been a 5min
>> tweak took over an hour! I guess that the wrappers are custom
>> command/targets in CMake and that the dependency is not set correctly.
>> Am I right? I'm happy to file a bug report if this something that you'd
>> be willing to fix. ;-)
> Sorry for the delay, I'm quite backlogged on this list.
>
> Using `ninja -d explain -n` on a completed OpenGL build shows 12000+
> targets need rebuilt when changing from OpenGL -> OpenGL2. The vast
> majority are from RenderingCore being linked ~everywhere. I do, however,
> see that lots of Python wrapping gets re-done that shouldn't be (namely
> vtkCommonCorePythonD due to a command-line change).
>
> It has `-IRending/OpenGL2` on its command line in the generated build.
> This is likely the cause of quite a few rebuilds, but there are still
> probably ~8000 or so required targets (at a guess). One problem is
> caused by the foreach loop in Wrapping/Python/CMakeLists.txt where
> `vtk_add_python_wrapping` is called. The directory-level
> `include_directories` are accumulating between each loop, so any module
> later in the list gets any module earlier's complete include line as
> well. Not sure why, exactly, RenderingCore and related module includes
> get into CommonCore's include directories.
>
> --Ben