I've been working on a patch that allows Kudu to be built outside of the source tree. The idea is that the directory you're in when you run cmake becomes your build directory. In doing so, each cmake run (often with differing configuration options) yields a different build directory. For example: $ cd kudu $ mkdir -p build/debug $ mkdir -p build/tsan $ cd build/debug $ cmake ../.. $ make $ cd ../tsan $ cmake -DKUDU_USE_TSAN=1 ../.. $ make
In this example, "build/debug" contains a debug Kudu build while "build/tsan" contains a TSAN-instrumented Kudu build. You can continue editing code in the single source tree and rebuilding both builds as you see fit, which can be useful. If you're already familiar with cmake-based projects, you're probably used to this, but it's fairly novel outside of cmake. I'm not aware of such a feature in autotools, for example. Many cmake-based projects that support this also forbid building in the source tree. Continuing the previous example, that would mean the following sequence of commands: $ cd kudu $ cmake . Why forbid this? 1. There's a cmake quirk where even if there's logic to forbid an in-tree build, cmake still writes out some files that prevent future out-of-tree builds from working correctly (until they are removed). Some projects go as far as to delete these intermediate files on build failure, a solution that makes me nervous. 2. Similar to #1, if everyone is forced to build out-of-tree, we'll know very quickly if someone accidentally introduces a change that breaks out-of-tree builds (i.e. uses the cmake variable CMAKE_SOURCE_DIR instead of CMAKE_BINARY_DIR). 3. It yields a more consistent experience vis a vis other cmake-based projects (like LLVM). The transition to forced out-of-tree builds will be disruptive, as today Kudu only supports in-tree builds. If you're building Kudu and you have an opinion one way or the other on this, I'd appreciate your feedback. You can reply to this e-mail, or (preferably) to this code review: http://gerrit.cloudera.org:8080/#/c/1762.
