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...<br><br><br>- 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<br>

<br>- 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.<br><br>- 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<br>

<br>- 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?<br><br>- could we have a nicer pretty print of of the modules, and have this come at the very end of the cmake output?<br>

<br>- in the cmake output, maybe say "3rd party library" instead of the TPL acronym as it currently is- "Processing TPL: ZLIB"<br><br>- are the modularization macros/functions reusable by other vtk based projects (like paraview)? or even for non vtk projects?<br>

<br>- I tried to use vtk from install dir:  error: vtkCommonCoreExport.h: No such file or directory<br><br>- We need a build target that compiles just the utilities like vtkWrapPython, vtkHashSource, etc.  This is useful for cross compiling.<br>

<br>-"Modularization", this means different things to different people. To be sure, there are lots of things we want<br>to get out of modularization.  One thing that I am interested in is static builds with minimal binary size.  This can be an important<br>

consideration when building for mobile devices and supercomputers (surprisingly similar constraints!)<br>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.<br>

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.<br>vtkAlgorithm calls vtkTable::SafeDownCast() simply to print an error message if something is a table. It depends on vtkGraph because some code<br>

in vtkAlgorithm::GetInputAbstractArrayToProcess() requires special handling of vtkGraph to access arrays.  Perhaps the special handling<br>could be refactored into a virtual method of vtkDataObject.  Anyway, this is just an example, food for thought.  There are plenty of other<br>

causes of bloat.  It would be neat if CDash could track bloat over time!<br><br>- static python wasn't working, here some notes:<br><br>(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)<br>

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

<br>2) vtkpython is built before the vtk kits are processed, this breaks for the static python case.<br> The vtkpython exe is added by Wrapping/Python/CMakeLists.txt, this accesses a cmake global property PY_STATIC_MODULES_LIST,<br>

 but this global property is not set until the vtk kits are wrapped.  The global property is set by<br> python_add_module, called from the function vtk_add_python_wrapping in vtkWrapping.py.<br><br>3) I was confused by all the dead cmake code in KitCommonBlock.cmake and KitCommonPythonWrapBlock.cmake, can this be removed?<br>

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

default to the value of BUILD_SHARED_LIBS, not TARGET_SUPPORTS_SHARED_LIBS.<br><br><br><br>VES notes:<br><br>-I put a minor patch in ThirdParty/freetype/vtkfreetype/CMakeLists.txt to compile vtkfreetype for iOS.<br> The patch sets VTKFREETYPE_MAC_FONT_SUPPORT to 0 even though if(APPLE) evaluates to TRUE, because<br>

 mac font support doesn't work on iOS.  I still need to determine the best way to test for iOS from cmake.<br><br>-I patch vtkFreeTypeTools.cxx to remove a somewhat trivial dependency on ftgl, then I remove the vtkftgl dependency from Rendering/Text/module.cmake<br>

 so that I can build vtkRenderingText without enabling vtkftgl. But vtkRenderingText has other classes that use ftgl in some way, so I just comment<br> 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?<br>

<br>- 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.<br><br>- VES uses vtkOutlineFilter, which currently lives in Filters/Core but it is commented out because it depends<br>

  on Filters/Sources/vtkOutlineSource.cxx.  I moved vtkOutlineFilter to Filters/Sources so it can compile,<br>  but this may not be good placement.<br><br>- I pushed these hacks required for building VES to the kiwi-fixes branch on git://<a href="http://gitorious.org/~patmarion/kitware/patmarion-vtkmodular.git">gitorious.org/~patmarion/kitware/patmarion-vtkmodular.git</a><br>

<br><br><br>