5

We are moving from MPC to CMake. We provide a lib with some samples. The samples are coming with makefiles.

The problem is that the makefiles, generated by cmake contains absolute paths but not relative ones:

# The main all target
all: cmake_check_build_system
    cd /.../Projects/cpp_trunk && $(CMAKE_COMMAND) -E cmake_progress_start /.../Projects/cpp_trunk/CMakeFiles /.../Projects/cpp_trunk/samples/CMakeFiles/progress.make
    cd /.../Projects/cpp_trunk && $(MAKE) -f CMakeFiles/Makefile2 samples/all
    $(CMAKE_COMMAND) -E cmake_progress_start /.../cpp_trunk/CMakeFiles 0

So, when it is copied it's become broken. It there any way to work it around?

UPD: I have read the FAQ, but my question is still taking place, perhaps somebody managed to get around?

4

3 回答 3

2

The makefiles created by CMake are not part of your source code base. The CMakeLists.txt files that you use as input to CMake are part of your source code base. When you copy your source code to a different place and want to build it there, build from your source code. That means re-running CMake. (And that's your workaround.)

I've been using CMake for over ten years continuously on one project. One of the handy tricks my team has learned is that you can have multiple copies of one part of your source code base on one development host that all share the same copy of the rest of your source code base. Try doing that with relative paths! We rely on the fact that every time we build source code in a new build directory, CMake will figure out the correct paths to all the source files, which are not necessarily the same relative to the new build directory as they were in the previous build.

于 2014-06-25T21:59:53.760 回答
2

What I've done to get around this sort of thing is write a small wrapper Makefile around cmake. I put the Makefile at the project root, with contents like this:

all: cmake

cmake:
    [ -f build/CMakeCache.txt ] && [ "$$(pwd)" != "$$(grep 'CMAKE_HOME_DIRECTORY:INTERNAL' build/CMakeCache.txt | cut -d '=' -f 2)" ] \
&& rm -rf build || true
    mkdir -p build && cd build && cmake ..
    make -C build

clean:
    rm -rf build

There's probably a cleaner way to do it, but it works for me:

make # build in one directory
cd ..
olddir=$(basename $OLDPWD) && rsync -ravz $olddir ${olddir}-test && cd ${olddir}-test # copy to another directory
make # running make in the new dir triggers a full rebuild
make # running make a second time in the new dir does not rebuild
于 2014-06-25T22:17:44.383 回答
0

The build files that are generated by cmake (makefiles, ninja files, etc), are going to have hardcoded paths and other not-portable stuff in them. That's ok. Treat them as temporary files that are part of the build process. You will only version the CMakeLists.txt files, and then generate new makefiles (or whatever) on other machines or in other directories when you check it out. You can even have different people on the team using different build files - one person using makefiles, one person using eclipse+ninja, etc, all generated by cmake.

于 2014-06-25T21:38:01.263 回答