steve naroff <snaroff@apple.com> writes:
Can you describe on which scenario do you require to move around build
trees?
Sure...
[explanation snipped]
Thanks for any help with this,
If you require this for VS only, the
set(CMAKE_USE_RELATIVE_PATHS ON)
trick mentioned on this thread may work, as Windows in general and the
LLVM project files in particular doesn't use absolute paths as much as
the POSIX platforms do (for RPATH, executing external commands,
etc). Please give it a try.
If there are absolute paths remaining on the VS project files, they may
be the result of generating them in the LLVM CMake files with the
`abspath' operator, or could come from CMake built-in variables that
default to the absolute form. We could see if those could be replaced by
relative paths.
I didn’t know about cmake and llvm! I will try it, thanks!
Regards,
Makslane
Hi,
Hmmm...
CMAKE_USE_RELATIVE_PATHS
Use relative paths (May not work!).
If this is set to TRUE, then the CMake will use relative paths between
the source and binary tree. This option does not work for more
complicated projects, and relative paths are used when possible. In
general, it is not possible to move CMake generated makefiles to a
different location regardless of the value of this variable.
I have seen those warnings as well, but it works and it solves the problem of having portable vcprof-file which was generated. (that what I thought was one of the questions in that thread)
In addition we are setting
set(CMAKE_SUPPRESS_REGENERATION ON)
in order to not have a dependency on the CMakeLists when creating the
vcproj-file.
This looks like asking for trouble. Why are you doing this?
To generate an independent vcproj-file from a CMakeFile. Here, we don't want/can't send the CMakeLists.txt to the other users and force them to use Cmake. They are expecting a vcproj-file. Using it this way simplifies my life of having only one build system for Linux/Windows...
Patrick.