CMake cache scripts pre-populate the CMakeCache in a build directory with commonly used settings.
The CMake invocation from D61952 could look like this:
cmake -G Ninja -C /path/to/llvm-project/lldb/cmake/caches/Apple-lldb-osx.cmake -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi;lldb" ../llvm-project/llvm
Options specified on the command line will override options in the cache files (as long as caches don't use FORCE).
What do you think? (This is a first proposal and not set in stone.)
Follow-up from: https://reviews.llvm.org/D61956?id=199645#inline-550727
It's been a pragmatic decision. Maybe we can improve this. The rationale was, that the default configuration should give the user something that works without touching caches or overriding parameters. In a previous sketch I used a real-world destination like:
But then ninja install would fail by default due to lack of permissions in the install destination. Actual release configurations tend to be more complex anyway and vendors will have their own downstream repos / caches for it. Thus, choosing a good default for developers sounded like a good way forward. What do you think?
What exactly do you mean? Having absolute paths, or paths into the build-tree, or the CMAKE_CURRENT_BINARY_DIR specifically? I don't see problems with the two last points. Am I missing something?
For the first: choosing an absolute path was for consistency with LLDB_FRAMEWORK_INSTALL_DIR. In the current build logic, they can both be absolute paths. Otherwise:
Clang cache scripts seem to accomplish it manually, which may look like this (but the default would again fail due to privileges):
Would you (and other reviewers) prefer this solution?