get_target_property(... LOCATION) has never worked 100% reliably across all platforms... Its use should be eliminated.<div><br></div><div>For add_custom_command use within a VTK CMakeLists.txt file, please use simply the name of the cmake target, not a reference to the executable file.</div>
<div><br></div><div>Thanks,</div><div>David Cole</div><div><br><div><br><div class="gmail_quote">On Wed, Sep 8, 2010 at 8:40 AM, 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;">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>
<div class="im"> SET(VTK_WRAP_TCL_EXE vtkWrapTcl)<br>
SET(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit)<br>
</div> ELSE(CMAKE_GENERATOR MATCHES "Visual Studio 7.*")<br>
<div class="im"> GET_TARGET_PROPERTY(VTK_WRAP_TCL_EXE vtkWrapTcl LOCATION)<br>
GET_TARGET_PROPERTY(VTK_WRAP_TCL_INIT_EXE vtkWrapTclInit LOCATION)<br>
</div> 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) 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>
<font color="#888888"><br>
David<br>
</font><div><div></div><div class="h5"><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>> wrote:<br>
>> That executable is in the bin tree. Actually I looked into this a 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 (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>
>> "${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>> wrote:<br>
>>>><br>
>>>> Does anyone know anything about DASH1 and DASH11? These machines 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 <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>
</div></div></blockquote></div><br></div></div>