Excellent! Thanks David!<br><br><div class="gmail_quote">On Thu, Sep 9, 2010 at 3:31 PM, David Gobbi <span dir="ltr"><<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I've removed GET_TARGET_PROPERTY(... LOCATION) throughout VTK. I did<br>
the wrapper executables yesterday, and since the dashboards didn't<br>
complain, I did the rest today.<br>
<font color="#888888"><br>
David<br>
</font><div><div></div><div class="h5"><br>
<br>
On Wed, Sep 8, 2010 at 8:34 AM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
> Hi David (Cole):<br>
><br>
> I'll make sure the wrappers do this. But is there a reliable way for<br>
> me to get the full path so that I can store it in VTKConfig.cmake?<br>
><br>
> David<br>
><br>
><br>
> On Wed, Sep 8, 2010 at 7:46 AM, David Cole <<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>> wrote:<br>
>> get_target_property(... LOCATION) has never worked 100% reliably across all<br>
>> platforms... Its use should be eliminated.<br>
>> For add_custom_command use within a VTK CMakeLists.txt file, please use<br>
>> simply the name of the cmake target, not a reference to the executable file.<br>
>> Thanks,<br>
>> David Cole<br>
>><br>
>> On Wed, Sep 8, 2010 at 8:40 AM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi Dave,<br>
>>><br>
>>> I tried your suggestion of using the executable target name in<br>
>>> ADD_CUSTOM_COMMAND instead of using the full path to the executable.<br>
>>> It worked nicely, so I added the following code to CMakeLists.txt to<br>
>>> get DASH1 and DASH11 running again:<br>
>>><br>
>>> # The LOCATION doesn't seem to work on Visual Studio 7<br>
>>> IF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*")<br>
>>> SET(VTK_WRAP_TCL_EXE vtkWrapTcl)<br>
>>> SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit)<br>
>>> ELSE(CMAKE_GENERATOR MATCHES "Visual Studio 7.*")<br>
>>> GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE vtkWrapTcl LOCATION)<br>
>>> GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION)<br>
>>> ENDIF(CMAKE_GENERATOR MATCHES "Visual Studio 7.*")<br>
>>><br>
>>> This works as a quick fix. The proper fix would be to use just<br>
>>> "vtkWrapTcl" when vtkWrapTcl.cmake is called from VTK, but to use the<br>
>>> full path when vtkWrapTcl.cmake is called from external packages.<br>
>>> This "proper fix" would be easy except for this nasty piece of code in<br>
>>> CMakeLists.txt:<br>
>>><br>
>>> # Save these in cache as other projects including VTK (such as ParaView)<br>
>>> may<br>
>>> # want to use these.<br>
>>> SET(VTK_WRAP_PYTHON_EXE<br>
>>> "${VTK_WRAP_PYTHON_EXE}"<br>
>>> CACHE INTERNAL "Location of program to do Python wrapping")<br>
>>> SET(VTK_WRAP_PYTHON_INIT_EXE<br>
>>> "${VTK_WRAP_PYTHON_INIT_EXE}"<br>
>>> CACHE INTERNAL "Location of program to do Python wrapping")<br>
>>><br>
>>> Hopefully this is legacy code.<br>
>>><br>
>>> David<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> On Tue, Sep 7, 2010 at 1:16 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
>>> > Thanks. That confirms my suspicion that it is a CMake issue. I was<br>
>>> > hoping that those machines were just broken somehow. Sigh.<br>
>>> ><br>
>>> > David<br>
>>> ><br>
>>> ><br>
>>> > On Tue, Sep 7, 2010 at 1:06 PM, Dave Partyka <<a href="mailto:dave.partyka@kitware.com">dave.partyka@kitware.com</a>><br>
>>> > wrote:<br>
>>> >> That executable is in the bin tree. Actually I looked into this a<br>
>>> >> little bit<br>
>>> >> a week ago or so when I noticed it but was side tracked.<br>
>>> >> In the top level CMakeLists.txt file of VTK I don't think<br>
>>> >> GET_TARGET_PROPERTY(.. LOCATION) is returning a path VS71 likes<br>
>>> >> (.\<executabe>).<br>
>>> >> IF(CMAKE_CROSSCOMPILING)<br>
>>> >> SET(VTK_WRAP_TCL_EXE vtkWrapTcl)<br>
>>> >> SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit)<br>
>>> >> ELSE(CMAKE_CROSSCOMPILING)<br>
>>> >> GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE vtkWrapTcl LOCATION)<br>
>>> >> GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION)<br>
>>> >> ENDIF(CMAKE_CROSSCOMPILING)<br>
>>> >> That said, the ADD_CUSTOM_COMMAND in vtkWrapTcl.cmake and<br>
>>> >> vtkWrapPython.cmake could probably just use the target name<br>
>>> >> (vtkWrapTcl,<br>
>>> >> vtkWrapPython) and let CMake figure out the path on it's own instead of<br>
>>> >> using whatever VTK_WRAP_{TCL/PYTHON}_EXE gets set to.<br>
>>> >> # add custom command to output<br>
>>> >> ADD_CUSTOM_COMMAND(<br>
>>> >> OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx<br>
>>> >> DEPENDS ${VTK_WRAP_TCL_EXE} ${VTK_WRAP_HINTS}<br>
>>> >> ${KIT_HIERARCHY_FILE}<br>
>>> >> MAIN_DEPENDENCY "${TMP_INPUT}"<br>
>>> >> COMMAND ${VTK_WRAP_TCL_EXE}<br>
>>> >> ARGS<br>
>>> >> ${TMP_CONCRETE}<br>
>>> >> ${TMP_HINTS}<br>
>>> >> ${TMP_HIERARCHY}<br>
>>> >> ${TMP_DEFINITIONS}<br>
>>> >> ${TMP_INCLUDE}<br>
>>> >> "${quote}${TMP_INPUT}${quote}"<br>
>>> >><br>
>>> >> "${quote}${CMAKE_CURRENT_BINARY_DIR}/${TMP_FILENAME}Tcl.cxx${quote}"<br>
>>> >> COMMENT "Tcl Wrapping - generating ${TMP_FILENAME}Tcl.cxx"<br>
>>> >> ${verbatim}<br>
>>> >> )<br>
>>> >><br>
>>> >> I'll let you take it from there :-P<br>
>>> >><br>
>>> >> On Tue, Sep 7, 2010 at 2:47 PM, Dave Partyka <<a href="mailto:dave.partyka@kitware.com">dave.partyka@kitware.com</a>><br>
>>> >> wrote:<br>
>>> >>><br>
>>> >>> Sure thing.<br>
>>> >>><br>
>>> >>> On Tue, Sep 7, 2010 at 2:38 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>><br>
>>> >>> wrote:<br>
>>> >>>><br>
>>> >>>> Does anyone know anything about DASH1 and DASH11? These machines<br>
>>> >>>> have<br>
>>> >>>> been complaining that "vtkWrapTcl.exe is not found" for several days<br>
>>> >>>> now. I have a vague feeling that they might be failing because of<br>
>>> >>>> something that I've done. Is there someone who can check to see if<br>
>>> >>>> vtkWrapTcl.exe is being built on these machines?<br>
>>> >>>><br>
>>> >>>> Thanks in advance,<br>
>>> >>>><br>
>>> >>>> David<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<br>
>>> >>>> <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>
>>> >>><br>
>>> >><br>
>>> >><br>
>>> ><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<br>
>>> <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>
>><br>
>><br>
><br>
</div></div></blockquote></div><br>