[CMake] absolute to relative paths

[Rolf Eike Beer]

Am Samstag, 4. Dezember 2010 schrieb Soeren Freudiger:
> Hello
> I know that the usage of relatives path out of the sources seems to be not
> an easy one. But maybe you can give me a workaround.
> 
> We use following directory structure
> 
> - dev
> 
>    |--project1: CMakeLists.txt
>    |
>    |            main.cpp
>    |            stdafx.h
>    |            project1.vcproj
>    |            ...
> 
>     --project2: CMakeLists.txt
> 
>    |            main.cpp
>    |            stdafx.h
>    |            project2.vcproj
>    |            ...
> 
>     --folder3
> 
>    |      |------- project3: CMakeLists.txt
>    |      |
>    |                         main.cpp
>    |                         stdafx.h
>    |                         project3.vcproj
>    |                         ...
>    |
>    |--sharedSrc
>    |
>           |-- folder1: *.cxx; *.h
>           |
>           |-- folder2: *.cxx; *.h
>           |
>           |-- folder4: *.cxx; *.h
> 
> Ok. As you can see, we are building the vcproj inside the project folders.
> source and binary path are identical. The problem is that all file paths
> to files in shared are absolute. Yes, I read the FAQ, yes, I see that's
> the philosophy of CMake. But our vcproj is also in the hg-repository for
> nightly builds and the dev dir is located in another directory and drive.
> The 3rd party dependencies are the same. So it doesn't work without
> reconfigure.

Well, the simple answer is: don't check in generated files. Just run CMake 
whenever they are needed (e.g. for nightly builds). That would allow you to 
use e.g. NMake Makefiles in nightly builds with the help of JOM, which can 
schedule the build jobs properly on multicore machines.

YMMV, but that's how it works.

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://www.cmake.org/pipermail/cmake/attachments/20101204/526a66ac/attachment.pgp>