[vtk-developers] DASH1 and DASH11 dashboards

[David Gobbi]

I've removed GET_TARGET_PROPERTY(... LOCATION) throughout VTK.  I did
the wrapper executables yesterday, and since the dashboards didn't
complain, I did the rest today.

  David


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