given: cmake -H/foo -B/bar
在执行期间/foo/CMakeLists.txt
:
${CMAKE_CURRENT_SOURCE_DIR} = /foo
${CMAKE_CURRENT_BINARY_DIR} = /bar
声明后project(Foo)
${PROJECT_SOURCE_DIR} = /foo
${PROJECT_BINARY_DIR} = /bar
然后在声明期间add_subdirectory(foo2)
,即执行/foo/foo2/CMakeLists.txt
:
${CMAKE_CURRENT_SOURCE_DIR} = /foo/foo2
${CMAKE_CURRENT_BINARY_DIR} = /bar/foo2
${PROJECT_SOURCE_DIR} = /foo
${PROJECT_BINARY_DIR} = /bar
如果我们遇到另一个嵌套项目:project(Bar)
${CMAKE_CURRENT_SOURCE_DIR} = /foo/foo2
${CMAKE_CURRENT_BINARY_DIR} = /bar/foo2
${PROJECT_SOURCE_DIR} = /foo/foo2
${PROJECT_BINARY_DIR} = /bar/foo2
还有许多其他变量可以帮助您准确定位文件,请参阅
https://cmake.org/Wiki/CMake_Useful_Variables https://cmake.org/Wiki/CMake_Useful_Variables
命令如add_executable
会尝试“找出”非显式文件在哪里,但在复杂的项目中依赖它并不是一个好主意。最好显式提供路径(使用可用的 CMAKE 变量)。
最后,如果你经常使用 cmake,你会得出这样的结论:源文件组织是它的弱点。
如果你像我一样幸运的话,你会偶然发现Sugar
包裹:
https://github.com/ruslo/sugar https://github.com/ruslo/sugar
您所有的源文件(和文档)问题都将消失。
如果你交叉编译,你会需要 Polly:
https://github.com/ruslo/polly https://github.com/ruslo/polly
如果您依赖常见的第 3 方库,您可能会从 Hunter 中受益:
https://github.com/ruslo/hunter https://github.com/ruslo/hunter