<br><br><div class="gmail_quote">On Sun, Mar 25, 2012 at 9:47 PM, Marcus D. Hanwell <span dir="ltr"><<a href="mailto:marcus.hanwell@kitware.com">marcus.hanwell@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Sun, Mar 25, 2012 at 8:14 PM, Pat Marion <<a href="mailto:pat.marion@kitware.com">pat.marion@kitware.com</a>> wrote:<br>
> I spent some time playing with VTK modular today. It's looking great, and<br>
> it wasn't too difficult to update VES for the latest master, awesome work<br>
> guys! Here are my notes...<br>
><br>
</div>Great.<br>
<div class="im">><br>
> - doc string for the cmake variable BUILD_SHARED_LIBS still says "Build<br>
> Verdict with shared libraries", maybe it's time to fix this bug now<br>
><br>
</div>I guess that is the last option call winning on the doc string. I will<br>
remove the line from verdict.<br>
<div class="im"><br>
> - while we're redoing the cmake code... in my opinion, there is too much<br>
> cmake variable clutter. I think more variables should be marked as<br>
> advanced.<br>
><br>
</div>I will take a look at this, it would be good to keep them sensible.<br>
<div class="im"><br>
> - can we add a way to override the module on/off defaults? I'd like to have<br>
> a way to force all modules to default to OFF during the first cmake run.<br>
> This is useful for superbuilds where I want everything off, with a specific<br>
> set enabled. Something like: -DVTK_MODULE_DEFAULT_STATE=OFF<br>
> -DModule_vtkFiltersGeoemtry=ON<br>
<br>
</div>This is temporary. I will see about fixing this up tomorrow. The plan<br>
is all off by default, with groups that are use visible to turn on<br>
related modules to make it easy for those that don't want to click<br>
through all of the variables.<br></blockquote><div><br>You may want to have a look at what we did in CTK. See:<br> - <a href="https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L350">https://github.com/commontk/CTK/blob/master/CMakeLists.txt#L350</a><br>
- <a href="https://github.com/commontk/CTK/blob/master/CMake/ctkMacroOptionUtils.cmake#L64">https://github.com/commontk/CTK/blob/master/CMake/ctkMacroOptionUtils.cmake#L64</a><br> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">><br>
> - If I do a clean configure, then turn off some modules and reconfigure,<br>
> then I get new Module_* cmake cache variables, why not add them all to the<br>
> cache on the first pass?<br>
<br>
</div>I will look into it.<br>
<div class="im">><br>
> - could we have a nicer pretty print of of the modules, and have this come<br>
> at the very end of the cmake output?<br>
<br>
</div>There is some code Alex was working on for KDE I was hoping to look<br>
into. Agreed, we should try and do better here.<br>
<div class="im">><br>
> - in the cmake output, maybe say "3rd party library" instead of the TPL<br>
> acronym as it currently is- "Processing TPL: ZLIB"<br>
<br>
</div>This is debug code that I have removed.<br>
<div class="im">><br>
> - are the modularization macros/functions reusable by other vtk based<br>
> projects (like paraview)? or even for non vtk projects?<br>
<br>
</div>ParaView is planning to re-use, we may need to change them a little to<br>
ensure this works.<br>
<div class="im">><br>
> - I tried to use vtk from install dir: error: vtkCommonCoreExport.h: No<br>
> such file or directory<br>
<br>
</div>That is an easy fix, I will get on that. Haven't gotten back to<br>
testing against installed VTK.<br>
<div class="im">><br>
> - We need a build target that compiles just the utilities like<br>
> vtkWrapPython, vtkHashSource, etc. This is useful for cross compiling.<br>
><br>
> -"Modularization", this means different things to different people. To be<br>
> sure, there are lots of things we want<br>
> to get out of modularization. One thing that I am interested in is static<br>
> builds with minimal binary size. This can be an important<br>
> consideration when building for mobile devices and supercomputers<br>
> (surprisingly similar constraints!)<br>
> Even after employing all the tricks to achieve minimal size, there is<br>
> sometimes a big difference between what the linker says is required, and<br>
> what I think should be required.<br>
> For example, the nm tool shows that vtkAlgorithm.cxx.o requires vtkGraph and<br>
> vtkTable, and the linker agrees. But I say we could drop that weight.<br>
> vtkAlgorithm calls vtkTable::SafeDownCast() simply to print an error message<br>
> if something is a table. It depends on vtkGraph because some code<br>
> in vtkAlgorithm::GetInputAbstractArrayToProcess() requires special handling<br>
> of vtkGraph to access arrays. Perhaps the special handling<br>
> could be refactored into a virtual method of vtkDataObject. Anyway, this is<br>
> 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>
</div>I think this is outside the scope of this work, but I couldn't agree<br>
more and I would like to see us being much more careful about<br>
introducing dependencies like this.<br>
<div class="im">><br>
> - static python wasn't working, here some notes:<br>
><br>
> (static python means that everything is linked into vtkpython, or paraview,<br>
> or whatever the final binary is. When you import vtkFilteringCorePython,<br>
> instead of doing a dlopen on vtkFilteringCorePython.so, python recognizes<br>
> this module as a built-in. This is fairly easy to do in practice, a cmake<br>
> macro configures a header file to be included by the exe)<br>
><br>
> 1) vtkmodular includes hacks vtkPythonAppInit.cxx that should be reverted.<br>
> I'm not sure if we still need the includes<br>
> for the kit instantiators, but we do need #include <vtkpythonmodules.h> and<br>
> CMakeLoadAllPythonModules();<br>
<br>
</div>We will not be building the instantiators by default, I will look into<br>
that code. Is there a dashboard for this anywhere? I will see if I can<br>
get a build working as I have never used VTK Python in this way<br>
before.<br>
<div class="im">><br>
> 2) vtkpython is built before the vtk kits are processed, this breaks for the<br>
> static python case.<br>
> The vtkpython exe is added by Wrapping/Python/CMakeLists.txt, this accesses<br>
> a cmake global property PY_STATIC_MODULES_LIST,<br>
> but this global property is not set until the vtk kits are wrapped. The<br>
> global property is set by<br>
> python_add_module, called from the function vtk_add_python_wrapping in<br>
> vtkWrapping.py.<br>
<br>
</div>We are fixing the build order, so Wrapping will be added for the<br>
wrapper generators, then all modules processed, and then the Tcl,<br>
Python and Java directories will be added after that. We have noticed<br>
several blocks of code requiring this order.<br>
<div class="im">><br>
> 3) I was confused by all the dead cmake code in KitCommonBlock.cmake and<br>
> KitCommonPythonWrapBlock.cmake, can this be removed?<br>
<br>
</div>Yes - I will be marking them as ignored. None of them are used.<br>
<div class="im">><br>
> 4) It would be great to somehow move the PYTHON_ADD_MODULE and<br>
> PYTHON_WRITE_MODULES_HEADER macros out of<br>
> FindPythonLibs.cmake, and remove FindPythonLibs.cmake from VTK. If/when<br>
> this happens, I have an edit<br>
> I'd like to make to the PYTHON_ADD_MODULE macro: the option<br>
> PYTHON_MODULE_${_NAME}_BUILD_SHARED should<br>
> default to the value of BUILD_SHARED_LIBS, not TARGET_SUPPORTS_SHARED_LIBS.<br>
><br>
</div>I was planning to remove FindPythonLibs, as CMake has a current copy.<br>
I am not sure about removing stuff from there though, I will check on<br>
backwards compatibility requirements but I think CMake is pretty<br>
strict. We could always add another, and forward the original to the<br>
new.<br>
<div><div class="h5">><br>
> VES notes:<br>
><br>
> -I put a minor patch in ThirdParty/freetype/vtkfreetype/CMakeLists.txt to<br>
> compile vtkfreetype for iOS.<br>
> The patch sets VTKFREETYPE_MAC_FONT_SUPPORT to 0 even though if(APPLE)<br>
> evaluates to TRUE, because<br>
> mac font support doesn't work on iOS. I still need to determine the best<br>
> way to test for iOS from cmake.<br>
><br>
> -I patch vtkFreeTypeTools.cxx to remove a somewhat trivial dependency on<br>
> ftgl, then I remove the vtkftgl dependency from Rendering/Text/module.cmake<br>
> so that I can build vtkRenderingText without enabling vtkftgl. But<br>
> vtkRenderingText has other classes that use ftgl in some way, so I just<br>
> comment<br>
> those out because they are not used by VES. So I'm still in search of a<br>
> better solution here. Perhaps it's possible to completely remove ftgl from<br>
> vtk?<br>
><br>
> - I have to comment out vtkFLUENTReader.cxx, the apple compiler chokes on<br>
> this file when using the -Os flag and targeting iOS. Compiler is<br>
> 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<br>
> commented out because it depends<br>
> on Filters/Sources/vtkOutlineSource.cxx. I moved vtkOutlineFilter to<br>
> 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<br>
> git://<a href="http://gitorious.org/%7Epatmarion/kitware/patmarion-vtkmodular.git" target="_blank">gitorious.org/~patmarion/kitware/patmarion-vtkmodular.git</a><br>
><br>
</div></div>Thanks for the extensive notes Pat. We will work on getting them integrated.<br>
<br>
Marcus<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>+1 919 869 8849<br><br>