CMake/CMakeLists.txt:如何显式列出文件(避免使用GLOB)

Question

我是CMake的新手。现在，我在我的Android/Java/JNI/CMake项目中使用了CMakeLists.txt文件中的以下代码：

include_directories(lib1)
file(GLOB_RECURSE LIB1_SOURCES
"bund.cc"
"bund.h"
"bund_io.cc"
"bund_io.h"
"cam.cc"
"cam.h"
"defines.h"
)

include_directories(lib2)
file(GLOB_RECURSE LIB2_SOURCES
"allocator.h"
"memory.h"
"arguments.cc"
"arguments.h"
"defines.h"
)

add_library(native-lib SHARED ${LIB1_SOURCES} ${LIB2_SOURCES} native-lib.cpp)
find_library(log-lib log)
target_link_libraries(native-lib ${log-lib})

由于CMake documentation“不建议使用GLOB从源码树中收集源文件列表”，我想知道在我的CMakeLists.txt中替换此代码的推荐方式是什么。请注意，我在lib1和lib2目录中都有一个‘fines.h’，可能需要采取一些特定的预防措施。

我的项目结构是：

-cpp (with mib-native.cpp and CMakeLists.txt inside)
--lib1 (with .h and .cc files mixed inside)
--lib2 (with .h and .cc files mixed inside)

我将不胜感激，如果你能提供详细的代码，我必须放在我的Android项目。

Answer 1

假设您有一些在库之间共享的依赖项，为什么不创建一个单独的依赖项并在其他两个目标中使用它呢？

此外，明确的源代码规范可能是最好的实践。在大项目中，不鼓励全局，创建相当小的目标，然后将其添加到更大的目标中。在您的例子中，我会创建两个库(和您一样)，但是会显式地列出源代码。

我会这样做：(首先尝试将代码拆分到库的目录中，最好为共享头文件创建一个文件夹)

# put all finds in one place
find_library(LOG_LIB log)

add_libary(LIB_1 STATIC
           ${CMAKE_CURRENT_LIST_DIR}/"bund.cc"
           ${CMAKE_CURRENT_LIST_DIR}/"bund_io.cc"
           ${CMAKE_CURRENT_LIST_DIR}/"cam.cc")

target_include_directories(LIB_1 
                           ${CMAKE_CURRENT_SOURCE_DIR}/lib1_includes
                           ${CMAKE_CURRENT_SOURCE_DIR}/common_includes)

add_libary(LIB_2 STATIC
           ${CMAKE_CURRENT_LIST_DIR}/"arguments.cc")

target_include_directories(LIB_2 
                           ${CMAKE_CURRENT_SOURCE_DIR}/lib2_includes
                           ${CMAKE_CURRENT_SOURCE_DIR}/common_includes)

add_library(NATIVE_LIB SHARED
            ${CMAKE_CURRENT_LIST_DIR}/native-lib.cpp)

target_link_libraries(NATIVE_LIB
                      PRIVATE 
                      ${LIB_1} ${LIB_2} ${LOG_LIB}) # I also prefer to use upper case for targets, otherwise you can have nasty to spot linking errors 

另一个想法是为库创建单独的目录树，并为它们创建CMakeFiles.txt，然后将它们用作目标。看看它是如何在here和附带的blog post中完成的。

您还将在那里了解私有关键字名称的含义(简而言之，它不会公开链接到您创建的库之外的库的符号。