[vtk-developers] Notes on VTK modularization

[Pat Marion]

I spent some time playing with VTK modular today.  It's looking great, and
it wasn't too difficult to update VES for the latest master, awesome work
guys!  Here are my notes...


- doc string for the cmake variable BUILD_SHARED_LIBS still says "Build
Verdict with shared libraries", maybe it's time to fix this bug now

- while we're redoing the cmake code... in my opinion, there is too much
cmake variable clutter.  I think more variables should be marked as
advanced.

- can we add a way to override the module on/off defaults?  I'd like to
have a way to force all modules to default to OFF during the first cmake
run.  This is useful for superbuilds where I want everything off, with a
specific set enabled.  Something like:  -DVTK_MODULE_DEFAULT_STATE=OFF
-DModule_vtkFiltersGeoemtry=ON

- If I do a clean configure, then turn off some modules and reconfigure,
then I get new Module_* cmake cache variables, why not add them all to the
cache on the first pass?

- could we have a nicer pretty print of of the modules, and have this come
at the very end of the cmake output?

- in the cmake output, maybe say "3rd party library" instead of the TPL
acronym as it currently is- "Processing TPL: ZLIB"

- are the modularization macros/functions reusable by other vtk based
projects (like paraview)? or even for non vtk projects?

- I tried to use vtk from install dir:  error: vtkCommonCoreExport.h: No
such file or directory

- We need a build target that compiles just the utilities like
vtkWrapPython, vtkHashSource, etc.  This is useful for cross compiling.

-"Modularization", this means different things to different people. To be
sure, there are lots of things we want
to get out of modularization.  One thing that I am interested in is static
builds with minimal binary size.  This can be an important
consideration when building for mobile devices and supercomputers
(surprisingly similar constraints!)
Even after employing all the tricks to achieve minimal size, there is
sometimes a big difference between what the linker says is required, and
what I think should be required.
For example, the nm tool shows that vtkAlgorithm.cxx.o requires vtkGraph
and vtkTable, and the linker agrees.  But I say we could drop that weight.
vtkAlgorithm calls vtkTable::SafeDownCast() simply to print an error
message if something is a table. It depends on vtkGraph because some code
in vtkAlgorithm::GetInputAbstractArrayToProcess() requires special handling
of vtkGraph to access arrays.  Perhaps the special handling
could be refactored into a virtual method of vtkDataObject.  Anyway, this
is just an example, food for thought.  There are plenty of other
causes of bloat.  It would be neat if CDash could track bloat over time!

- static python wasn't working, here some notes:

(static python means that everything is linked into vtkpython, or paraview,
or whatever the final binary is.  When you import vtkFilteringCorePython,
instead of doing a dlopen on vtkFilteringCorePython.so, python recognizes
this module as a built-in.  This is fairly easy to do in practice, a cmake
macro configures a header file to be included by the exe)

1) vtkmodular includes hacks vtkPythonAppInit.cxx that should be reverted.
I'm not sure if we still need the includes
for the kit instantiators, but we do need #include <vtkpythonmodules.h> and
CMakeLoadAllPythonModules();

2) vtkpython is built before the vtk kits are processed, this breaks for
the static python case.
 The vtkpython exe is added by Wrapping/Python/CMakeLists.txt, this
accesses a cmake global property PY_STATIC_MODULES_LIST,
 but this global property is not set until the vtk kits are wrapped.  The
global property is set by
 python_add_module, called from the function vtk_add_python_wrapping in
vtkWrapping.py.

3) I was confused by all the dead cmake code in KitCommonBlock.cmake and
KitCommonPythonWrapBlock.cmake, can this be removed?

4) It would be great to somehow move the PYTHON_ADD_MODULE and
PYTHON_WRITE_MODULES_HEADER macros out of
 FindPythonLibs.cmake, and remove FindPythonLibs.cmake from VTK.  If/when
this happens, I have an edit
I'd like to make to the PYTHON_ADD_MODULE macro:  the option
PYTHON_MODULE_${_NAME}_BUILD_SHARED should
default to the value of BUILD_SHARED_LIBS, not TARGET_SUPPORTS_SHARED_LIBS.



VES notes:

-I put a minor patch in ThirdParty/freetype/vtkfreetype/CMakeLists.txt to
compile vtkfreetype for iOS.
 The patch sets VTKFREETYPE_MAC_FONT_SUPPORT to 0 even though if(APPLE)
evaluates to TRUE, because
 mac font support doesn't work on iOS.  I still need to determine the best
way to test for iOS from cmake.

-I patch vtkFreeTypeTools.cxx to remove a somewhat trivial dependency on
ftgl, then I remove the vtkftgl dependency from Rendering/Text/module.cmake
 so that I can build vtkRenderingText without enabling vtkftgl. But
vtkRenderingText has other classes that use ftgl in some way, so I just
comment
 those out because they are not used by VES.  So I'm still in search of a
better solution here.  Perhaps it's possible to completely remove ftgl from
vtk?

- I have to comment out vtkFLUENTReader.cxx, the apple compiler chokes on
this file when using the -Os flag and targeting iOS.  Compiler is
i686-apple-darwin10-llvm-g++-4.2 (GCC) 4.2.1.

- VES uses vtkOutlineFilter, which currently lives in Filters/Core but it
is commented out because it depends
  on Filters/Sources/vtkOutlineSource.cxx.  I moved vtkOutlineFilter to
Filters/Sources so it can compile,
  but this may not be good placement.

- I pushed these hacks required for building VES to the kiwi-fixes branch
on git://gitorious.org/~patmarion/kitware/patmarion-vtkmodular.git
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20120325/99d674c0/attachment.html>