[Cmake] cmUtilitySourceCommand : why relative path to source ?

[William A. Hoffman]

The command is aimed at utilities that may or may not be part of the build.
For example, the new wrapping package CABLE can be installed or be part
of the source tree for the project you are working on.  For third-party 
stuff, FIND_FILE should
be used.

At 03:14 PM 8/19/2001 +0200, Sebastien BARRE wrote:
>Hi
>
>Syntax:
>UTILITY_SOURCE(cache_entry executable_name path_to_source [file1 file2 ...])
>
>Is there a reason for the path_to_source to be relative to the build 
>directory ? This looks odd, especially if this command is aiming at 
>third-party utilities support. If these are third-party tools, they might 
>be anywhere in the system, especially on a different drive.
>
>For example, say that I'm trying to build a lib with my own VTK classes 
>and I want to wrap them using the usual wrapper mechanism (provided that I 
>know the path to my VTK sources, say VTK_SOURCE_DIR). This will fail :
>
>   UTILITY_SOURCE(VTK_WRAP_TCL_EXE vtkWrapTcl ${VTK_SOURCE_DIR}/Wrapping 
> vtkWrapTcl.c)
>
>Of course, I can use something like that :
>
>   FIND_PROGRAM(VTK_WRAP_TCL_EXE vtkWrapTcl ${VTK_BINARY_RELEASE_DIR})
>but
>         a) VTK_BINARY_RELEASE is something that is not very easy to get 
> (or maybe I missed something), since it could be 
> c:/[...]/build/bin/Release, or c:/[...]/build/bin/Debug, thus it has to 
> be hardcoded.
>         b) vtkWrapTcl.exe might not have been built, thus I also need the 
> previous syntax (and I would build vtkWrapTcl myself as it's done in the 
> VTK/Wrapping/ dir)
>
>Thanks
>
>
>_______________________________________________
>Cmake mailing list
>Cmake at public.kitware.com
>http://public.kitware.com/mailman/listinfo/cmake