[vtk-developers] Re: VTKConfig.cmake new values

[Sebastien BARRE]

At 02:26 PM 2/28/2006, David Gobbi wrote:
>Brad King wrote:
>>David Gobbi wrote:
>>>I added two new values to VTKConfig.cmake last week 
>>>(VTK_EXECUTABLE_DIRS, VTK_RUNTIME_PATH_VAR_NAME, VTK_PYTHON_DIRS) 
>>>and thought that I should get in touch with you and Kitware to 
>>>make sure that these additions make sense.

Thanks David (especially after the amount of private emails we had 
about recent Python installation problems, I'm glad it's making its 
way to VTK).

>>>The VTK_PYTHON_DIRS addition is fairly minor by comparison, it 
>>>just contains the directories where the python modules (pure 
>>>python and binary) can be found so that it can be used to set the PYTHONPATH.
>>>Another option would be to set a VTK_PYTHON_HOME variable instead, 
>>>similar to the VTK_TCL_HOME, and generate Wrapping/Python/vtk.pth 
>>>so that it points to where the binary modules. This would make it 
>>>work similar to the way pkgIndex.tcl works.  Any opinions on 
>>>whether the VTK_PYTHON_HOME approach would be preferable?
>>
>>Whatever is closer to the python-world convention is probably best.
>Good point.  Maybe VTK_PYTHONPATH_DIRS would be more clear than 
>VTK_PYTHON_DIRS.

The problem is that it was just not working on Windows last week, 
because of the configuration types (Debug, Release, RelDebWithInfo, 
etc). I think you do not want to have, in the same variable, paths 
that make sense only when post-fixed with a config type, and paths 
that make sense only without.

For example, using Msnet2003, if I check my build tree:

SET(VTK_PYTHON_DIRS "d:/build/my 
dashboards/KWWidgets/Nightly/VTK-Win32-msnet2003-debug/Wrapping/Python;d:/build/my 
dashboards/KWWidgets/Nightly/VTK-Win32-msnet2003-debug/bin")

The first path:
d:/build/my 
dashboards/KWWidgets/Nightly/VTK-Win32-msnet2003-debug/Wrapping/Python
is just fine, it's where my vtk/*.py is.

The second path:
d:/build/my dashboards/KWWidgets/Nightly/VTK-Win32-msnet2003-debug/bin
required to be post-fixed with the config type to make any "sense" 
from a third-party point of view (which is the whole point of 
VTKConfig.cmake). It's in bin/Debug that my *PythonD.dll are.

So I can't just loop over VTK_PYTHON_DIRS and append config types for 
example. Or I guess I could do both, i.e. use all the paths in that 
var as is, then use all of them postfixed. I'm just worried I would 
"caught" something bad in between.

Now I know we discussed that privately, but I am confused right now: 
I'm looking at my dashboard, and I see my Wrapping/Python dir in the 
build tree now has Debug, Release, RelDebWithInfo subdirs with what 
seem to be a copy of what is in already Wrapping/Python/vtk/*.py. Did 
you add that ? That would solve the problem of the config type, i.e. 
that's great with me, but in that case we probably want one or the 
other, not both ?

Thanks

--
Sebastien Barre