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

[David Gobbi]

Sebastien BARRE wrote:
> 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).
Yeah, I wanted to get all over and done with a while ago, but the past 
week two weeks have been way too busy for me.

>>>> 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.
Yup, I finally fixed that over the weekend.  It isn't a nice fix, all I 
do is copy the python scripts into a bunch of subdirs named after the 
configuration types.

> 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.
After my weekend changes there are configuration subdirs in 
${VTK_BINARY_DIR}/Wrapping/Python, e.g. Wrapping/Python/Debug/vtk/*.py
>
> 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.
Hey, you're confusing the Python DLLs again.  It is the *Python.dlls 
that Python needs to find.  The *PythonD.dlls just need to be in PATH 
(or in LD_LIBRARY_PATH or rpath on unix).
> 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 ?
Yes, that is a recent fix, I meant to send you an email but I forgot.  I 
decided that there have to be configuration subdirs for 
Wrapping/Python.   Making extra copies of all the .py files is just a 
quick fix, eventually I want to change things so there is only a 
different vtk.pth file in each configuration subdir instead (just like 
there is a different pkgIndex.tcl for each configuration in the 
Wrapping/Tcl directory).

 - David