[Paraview-developers] wrapping cmake dependency issue?

[Ben Boeckel]

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