[CMake] Generator "Visual Studio 7 .NET 2003" fails to generate custom commands properly when explicit WORKING_DIRECTORY is given

[Bill Hoffman]

Gerhard Grimm wrote:
> Hi there!
>
> Using cmake 2.4.6, I encountered a problem with the Visual Studio projects
> generator and custom commands.
>
> My CMAKE_SOURCE_DIR is D:/Projekte/OSLO/src
> My CMAKE_BINARY_DIR is D:/Projekte/OSLO/build/win32debug
>
> My CMakeLists.txt in source subdirectory INST contains:
>
> add_custom_command(OUTPUT ${Pkg_setup_src}
>                    COMMAND ${PYTHON} 
>                    ARGS ${INST_TXTBUILD} ${Pkg_setup_src}
>                    WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR})
>
> where ${PYTHON} evaluates to an absolute Path:
> D:/Projekte/OSLO/build/win32debug/python/2_4_x/python_d.exe
>
> However, the project generator converts ${PYTHON} to a path relative to
> CMAKE_CURRENT_BINARY_DIR, which would have worked fine if WORKING_DIRECTORY
> had not been given. Alas, the generated command line for the above rule is:
>
> cd D:\Projekte\OSLO\src\INST
> ..\python\2_4_x\python_d.exe D:/Projekte/OSLO/src/INST/txtbuild.py [...]
>
> which is obviously going to fail, since the executable will not be found.
> Is there a way to tell the generator to not mess up absolute paths?
>   
This is a bug.   I just verified it.   The only work-arounds right now are:

1. do not put python in the same tree that you do the build in.
For example, this works:
D:/Projekte/OSLO/build2/win32debug/python/2_4_x/python_d.exe

2. Do not change the working directory, somehow give the path to the 
command line of your python script.

3.  Use the NMake makefiles which do not have this bug.

The bug is caused because cmake is creating a relative path, but not 
checking to see if
the working directory has been changed.

I will try to get a fix into the 2.4.7 when that comes out.

-Bill