当前位置：首页 > news >正文

CMake构建系统：从基础概念到大型C/C++项目实战指南

news 2026/8/23 2:49:49

1. 从“手工作坊”到“工业流水线”：为什么大型C/C++项目离不开CMake

如果你写过一些C/C++的小程序，可能觉得用gcc或clang直接敲命令编译也挺方便。一个g++ main.cpp -o app就搞定了。但当你开始接触一个包含几十个模块、依赖十几个第三方库、需要在Windows、Linux、macOS上都能编译运行的项目时，那种“手工作坊”式的编译方式会立刻让你崩溃。你会面临一堆问题：不同平台编译器选项怎么统一？库的依赖关系怎么管理？如何高效地组织源代码、头文件和生成的中间文件？这时候，一个强大的构建系统就成了必需品，而CMake，就是目前C/C++生态中当之无愧的“工业流水线”标准。

CMake本身不是一个编译器，而是一个构建系统生成器。你可以把它理解为一个“项目描述语言”的翻译官。你用CMake的语法（CMakeLists.txt文件）写下项目的构建规则，比如有哪些源文件、需要链接哪些库、编译选项是什么。然后，CMake会根据你当前的操作系统和开发环境，生成对应平台的原生构建文件。在Linux/macOS上，它生成Makefile；在Windows上，它可以生成Visual Studio的.sln解决方案文件；它还能生成Ninja、Xcode等项目的构建文件。这种“一次编写，到处生成”的特性，正是跨平台开发的基石。

我见过不少团队在项目初期图省事，用IDE自带的工程文件或者手写Makefile，等项目规模膨胀到几十万行代码时，构建脚本已经变成了一团无人敢碰的“祖传代码”，添加一个新平台的支持犹如噩梦。而从一开始就采用CMake，虽然学习曲线稍陡，但它带来的结构清晰、依赖明确、平台无关的优势，会在项目整个生命周期里持续带来回报。接下来，我们就深入这条“工业流水线”，看看如何用CMake设计和构建一个大型的、跨平台的C/C++项目。

2. 大型项目的CMake骨架设计：模块化与接口清晰化

一个大型项目绝不能把所有源代码都堆在一个目录下，然后用一个巨大的CMakeLists.txt文件来管理。那会是一场维护灾难。正确的做法是采用模块化的层次结构。通常，一个典型的大型项目骨架会像这样：

MyLargeProject/ ├── CMakeLists.txt # 根目录，项目总入口 ├── cmake/ # 存放自定义的CMake模块、Find脚本 │ └── FindSomeLib.cmake ├── third_party/ # 第三方依赖（可选，也可用包管理器） │ └── CMakeLists.txt ├── src/ # 项目主源代码 │ ├── CMakeLists.txt │ ├── core/ # 核心基础模块 │ │ ├── CMakeLists.txt │ │ ├── include/ │ │ └── src/ │ ├── network/ # 网络通信模块 │ │ ├── CMakeLists.txt │ │ ├── include/ │ │ └── src/ │ └── gui/ # 用户界面模块（如果跨平台，可能用Qt等） │ ├── CMakeLists.txt │ ├── include/ │ └── src/ ├── tests/ # 单元测试 │ ├── CMakeLists.txt │ └── ... ├── apps/ # 可执行程序入口 │ ├── CMakeLists.txt │ ├── cli_tool/ │ └── desktop_app/ ├── build/ # 构建输出目录（推荐外部构建） └── docs/ # 文档

这个结构的关键在于每个有源代码的子目录都是一个相对独立的CMake子项目，拥有自己的CMakeLists.txt。根目录的CMakeLists.txt负责定义项目全局属性、寻找编译器、设置编译选项，并通过add_subdirectory()命令将各个模块“组装”起来。

2.1 根目录CMakeLists.txt：定下全局基调

根目录的脚本是项目的总章程。它通常包含以下核心内容：

# 定义CMake的最低版本要求，确保能使用我们需要的特性 cmake_minimum_required(VERSION 3.16...3.28) # 定义项目名称、版本、支持的语言（C和C++） project(MyLargeProject VERSION 1.0.0 LANGUAGES C CXX) # 设置C++标准。这是大型项目稳定性的关键。 # 使用`PUBLIC`属性，意味着这个标准要求会传递给所有链接此项目的目标。 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 必须支持C++17，否则报错 set(CMAKE_CXX_EXTENSIONS OFF) # 禁用编译器扩展（如GNU的-std=gnu++17），保证代码可移植性 # 一个非常重要的最佳实践：将构建产物（二进制、库）输出到统一的目录，而不是和源码混在一起。 # 这能让你的源码目录保持干净。 set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) # 静态库 # 全局编译选项。注意，谨慎使用`add_compile_options`，因为它会影响所有目标。 # 更好的做法是通过`target_compile_options`针对特定目标设置。 # 这里可以设置一些最基础的警告级别。 if(MSVC) add_compile_options(/W4 /WX) # MSVC: 警告等级4，视警告为错误 else() add_compile_options(-Wall -Wextra -Wpedantic -Werror) # GCC/Clang: 开启大部分警告，视警告为错误 endif() # 引入子目录。顺序有时很重要，比如基础库必须先于依赖它的模块。 add_subdirectory(src/core) # 最基础、无依赖的模块最先 add_subdirectory(src/network) # 可能依赖core add_subdirectory(src/gui) # 可能依赖core和network add_subdirectory(apps) # 生成可执行文件，依赖所有库 add_subdirectory(tests) # 测试，依赖被测试的库

注意：关于CMAKE_CXX_STANDARD的设置位置。我强烈建议只在根目录的CMakeLists.txt中设置一次，并使用PUBLIC或INTERFACE属性通过目标传递。避免在每个子目录的CMakeLists.txt里重复设置，否则容易造成标准冲突或混淆。

2.2 模块级CMakeLists.txt：定义清晰的接口

以src/core模块为例，它的CMakeLists.txt应该专注于定义自己这个库。

# 首先，收集本模块的所有源文件。使用`aux_source_directory`简单但不够灵活（无法过滤头文件）。 # 更推荐显式列出，或者使用`file(GLOB ...)`但需注意其缺点（CMake官方不推荐用于源文件，因为新增文件不会自动触发重新生成构建系统）。 # 这里演示显式列出，适合中型模块。 set(CORE_SOURCES src/utils.cpp src/logger.cpp src/config.cpp ) set(CORE_HEADERS include/core/utils.h include/core/logger.h include/core/config.h ) # 关键命令：创建一个库目标。 # `SHARED`表示动态库，`STATIC`表示静态库。大型项目内部模块常用静态库以简化部署。 add_library(core STATIC ${CORE_SOURCES} ${CORE_HEADERS}) # 为这个库目标设置包含目录。 # `PUBLIC`意味着：1）编译core库本身时需要这些头文件；2）任何链接core库的其他目标也需要这些头文件路径。 target_include_directories(core PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> # 构建时 $<INSTALL_INTERFACE:include> # 安装后（如果将来要打包分发） ) # 为本库设置特定的编译选项。 target_compile_options(core PRIVATE -O2) # PRIVATE表示只影响core库自身的编译 # 如果core库依赖了第三方库（如Threads），在这里链接。 find_package(Threads REQUIRED) target_link_libraries(core PUBLIC Threads::Threads) # PUBLIC表示依赖会传递给链接core的目标 # 定义库的版本属性（可选，但对动态库很重要）。 set_target_properties(core PROPERTIES VERSION ${PROJECT_VERSION} SOVERSION ${PROJECT_VERSION_MAJOR} )

这里最重要的概念是目标（Target），如上面的core。在现代CMake（3.0+）实践中，一切围绕“目标”进行。你不再全局地设置包含目录和链接库，而是针对每个库或可执行文件目标，声明它需要什么（target_include_directories），它依赖什么（target_link_libraries）。这种声明方式具有传递性，能精确地管理依赖关系图，是构建大型复杂项目的核心。

3. 依赖管理：第三方库的引入与跨平台适配

大型项目不可能所有代码都自己写，必然会依赖第三方库，如JSON解析器（如nlohmann/json）、网络库（如Boost.Asio）、测试框架（如GoogleTest）。如何管理这些依赖，是跨平台构建的另一大挑战。

3.1 策略一：使用CMake的`find_package`（推荐）

这是最“CMake”的方式。许多成熟的C++库都提供了CMake的包配置文件（<PackageName>Config.cmake或Find<PackageName>.cmake）。你只需要一行命令：

find_package(Boost 1.70 REQUIRED COMPONENTS filesystem system)

CMake会自动在系统路径（如/usr/lib，C:\Program Files）或你设置的CMAKE_PREFIX_PATH中寻找这个库。如果找到，它会定义一些导入目标（如Boost::filesystem），你可以直接链接：

target_link_libraries(my_app PRIVATE Boost::filesystem Boost::system)

跨平台技巧：find_package的行为在不同平台可能不同。在Windows上，库可能没有安装在标准路径。你需要：

将库的安装路径（包含lib和include的目录）添加到系统的PATH或CMake的CMAKE_PREFIX_PATH环境变量中。
或者，使用-DCMAKE_PREFIX_PATH=<path_to_lib_root>参数在配置时传递给CMake。

3.2 策略二：将源码作为子模块（Submodule）纳入项目

对于一些轻量级、修改频繁、或系统包管理器没有的库，你可以将其源码直接放在项目的third_party目录下，并通过add_subdirectory()引入。例如，对于单头文件库nlohmann/json：

third_party/ └── json/ ├── include/nlohmann/json.hpp └── CMakeLists.txt (可能很简单，甚至没有)

在你的项目CMakeLists.txt中：

add_subdirectory(third_party/json) # 假设json库通过add_library创建了一个叫nlohmann_json的目标 target_link_libraries(my_app PRIVATE nlohmann_json)

优点：版本锁定，构建环境完全自包含，可移植性极强。缺点：会增加项目源码体积，并且你需要管理这些第三方库的更新。

3.3 策略三：使用CMake的FetchContent（现代方式）

FetchContent是CMake 3.11引入的模块，它允许你在配置阶段直接从Git仓库、URL等下载依赖的源码并自动将其引入构建。这结合了前两种方式的优点。

include(FetchContent) FetchContent_Declare( googletest GIT_REPOSITORY https://github.com/google/googletest.git GIT_TAG release-1.11.0 # 指定版本，保证可重复构建 ) FetchContent_MakeAvailable(googletest) # 之后就可以直接链接GTest提供的目标了 target_link_libraries(my_test PRIVATE GTest::gtest GTest::gtest_main)

这是目前管理开发期依赖（如测试框架）的首选方式。它干净、自动化，且不污染你的主源码目录。

3.4 处理平台差异：条件判断与抽象

跨平台代码中，总有一些平台特定的调用。在CMake中，你需要检测并处理这些差异。

# 检测操作系统 if(WIN32) # Windows特定设置 add_definitions(-DWIN32_LEAN_AND_MEAN) target_link_libraries(my_app PRIVATE ws2_32) # Windows sockets库 elseif(UNIX AND NOT APPLE) # Linux特定设置 target_link_libraries(my_app PRIVATE pthread dl) elseif(APPLE) # macOS特定设置 target_link_libraries(my_app PRIVATE "-framework CoreFoundation") endif() # 检测编译器 if(MSVC) target_compile_options(my_app PRIVATE /MP) # 启用多进程编译 # 关闭一些MSVC特有的安全警告（谨慎使用） target_compile_options(my_app PRIVATE /wd4996 /wd4267) elseif(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang") target_compile_options(my_app PRIVATE -pthread) endif()

实操心得：对于平台特定的源代码文件，不要用#ifdef _WIN32把代码全写在一个文件里。更好的做法是创建不同的源文件，如platform_win.cpp和platform_linux.cpp，然后在CMake中根据平台选择编译哪一个。这样代码更清晰，也便于CMake管理。
if(WIN32) target_sources(my_lib PRIVATE src/platform/platform_win.cpp) else() target_sources(my_lib PRIVATE src/platform/platform_linux.cpp) endif()

4. 高级特性应用：让构建系统更智能、更强大

掌握了基础结构和依赖管理，你已经能搭建一个稳健的大型项目了。但CMake的强大远不止于此，下面这些高级特性可以极大提升开发效率和项目质量。

4.1 生成器表达式：条件化的构建逻辑

生成器表达式（Generator Expressions）是CMake中非常强大但有点晦涩的特性。它允许你在生成构建系统时（而不是配置时）进行条件判断，主要用于设置那些依赖于构建配置（如Debug/Release）、目标平台、编译器的属性。

一个最常见的用途是设置不同构建类型的编译选项：

# 为`core`目标设置编译选项。Debug版本开启调试信息并优化等级低，Release版本激进优化。 target_compile_options(core PRIVATE $<$<CONFIG:Debug>:-O0 -g3> # 如果是Debug配置，使用-O0 -g3 $<$<CONFIG:Release>:-O3 -DNDEBUG> # 如果是Release配置，使用-O3并定义NDEBUG宏 $<$<CONFIG:RelWithDebInfo>:-O2 -g> # 带调试信息的发布版 )

另一个例子是处理编译器特定的警告标志：

target_compile_options(my_app PRIVATE $<$<CXX_COMPILER_ID:GNU>:-Wall -Wextra> $<$<CXX_COMPILER_ID:Clang>:-Wall -Weverything -Wno-c++98-compat> $<$<CXX_COMPILER_ID:MSVC>:/W4> )

生成器表达式也用于更精细地控制包含目录的传递：

target_include_directories(core INTERFACE $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include> $<INSTALL_INTERFACE:include> )

这里$<BUILD_INTERFACE:...>表示只有在构建本项目本身时才包含这个路径；$<INSTALL_INTERFACE:...>表示当这个库被安装后，其他项目通过find_package找到它时，应该去哪里找头文件。这是制作可分发库的关键。

4.2 交叉编译：为其他平台构建

CMake原生支持交叉编译。你需要准备一个工具链文件（Toolchain File），里面定义了目标平台的编译器、链接器、系统根目录等信息。

例如，一个为ARM Linux交叉编译的工具链文件arm-linux-gnueabihf.cmake：

# 指定交叉编译器和工具链前缀 set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER arm-linux-gnueabihf-g++) # 指定目标系统的根文件系统位置（sysroot） set(CMAKE_SYSROOT /path/to/arm-sysroot) set(CMAKE_FIND_ROOT_PATH ${CMAKE_SYSROOT}) # 调整find_*命令的搜索策略，只在sysroot中找 set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

然后在配置CMake时指定这个工具链文件：

cmake -S . -B build-arm -DCMAKE_TOOLCHAIN_FILE=arm-linux-gnueabihf.cmake

4.3 单元测试集成：使用CTest

CMake集成了CTest，一个简单的测试驱动器。你可以轻松地将测试用例的构建和运行纳入CMake流程。

首先，确保你通过FetchContent或find_package引入了Google Test（或其他测试框架）。然后，在tests/CMakeLists.txt中：

# 启用测试 enable_testing() # 创建一个测试可执行文件 add_executable(unit_tests test_core.cpp test_network.cpp ) target_link_libraries(unit_tests PRIVATE core network GTest::gtest GTest::gtest_main) # 使用add_test命令将可执行文件注册为测试 add_test(NAME CoreTests COMMAND unit_tests) # 你可以设置测试的属性，比如超时时间 set_tests_properties(CoreTests PROPERTIES TIMEOUT 30)

构建完成后，你可以在构建目录下运行ctest来执行所有测试。ctest提供了丰富的选项，如-V输出详细信息，-R按名称过滤测试，--output-on-failure在测试失败时打印输出，这些都能很好地集成到CI/CD流程中。

4.4 安装与打包：制作可分发的软件包

项目开发完成后，你可能需要将其安装到系统目录，或者打包成.deb、.rpm、.msi安装包。CMake的install()命令为此提供了支持。

# 在库或可执行目标的CMakeLists.txt中，添加install规则 # 安装动态库和头文件（以core库为例） install(TARGETS core EXPORT MyLargeProjectTargets # 将目标导出，供其他CMake项目使用 LIBRARY DESTINATION lib # 动态库安装到<prefix>/lib ARCHIVE DESTINATION lib # 静态库安装到<prefix>/lib RUNTIME DESTINATION bin # Windows上的DLL安装到<prefix>/bin INCLUDES DESTINATION include # 关联的头文件安装目录 ) # 安装头文件 install(DIRECTORY include/ DESTINATION include) # 安装可执行文件 install(TARGETS my_app RUNTIME DESTINATION bin) # 生成并安装一个CMake的包配置文件，让其他项目能用find_package找到你 install(EXPORT MyLargeProjectTargets FILE MyLargeProjectConfig.cmake NAMESPACE MyLargeProject:: DESTINATION lib/cmake/MyLargeProject ) # 生成一个基础的<PackageName>ConfigVersion.cmake文件，用于版本兼容性检查 include(CMakePackageConfigHelpers) write_basic_package_version_file( MyLargeProjectConfigVersion.cmake VERSION ${PROJECT_VERSION} COMPATIBILITY SameMajorVersion # 主版本号相同则兼容 ) install(FILES ${CMAKE_CURRENT_BINARY_DIR}/MyLargeProjectConfigVersion.cmake DESTINATION lib/cmake/MyLargeProject )

配置和构建时，使用-DCMAKE_INSTALL_PREFIX=<path>指定安装前缀。构建完成后，运行cmake --install build（CMake 3.15+）或make install即可完成安装。

对于制作系统包（如deb），CMake提供了CPack模块。在根CMakeLists.txt末尾加上：

include(CPack)

然后配置一些CPACK_*变量（如CPACK_PACKAGE_NAME,CPACK_PACKAGE_VENDOR），构建后运行cpack -G DEB就能生成一个deb包。虽然对于复杂的打包需求可能仍需自定义脚本，但CPack为简单的分发提供了极大便利。

5. 实战避坑：那些文档里不会写的教训

理论说再多，不如踩一次坑。下面是我在多年使用CMake构建大型跨平台项目过程中，总结的一些“血泪教训”和实用技巧。

5.1 外部构建与源码内构建

永远使用外部构建（Out-of-Source Build）。即在项目根目录外创建一个单独的build目录进行构建。

# 正确做法 mkdir build && cd build cmake .. make # 错误做法（源码内构建） cmake . make

外部构建的好处是：构建产生的所有文件（.o,.a,.so,Makefile,CMakeCache.txt等）都集中在build目录，与源码完全分离。你可以轻松地删除整个build目录来清理，也可以为不同的配置（如Debug/Release， x86/ARM）创建多个独立的build目录而互不干扰。

5.2 CMake缓存变量的“陷阱”

CMake在首次运行时，会将许多变量（如CMAKE_CXX_COMPILER,CMAKE_PREFIX_PATH）的值缓存到CMakeCache.txt文件中。后续再次运行cmake时，会直接使用缓存值，除非你显式地覆盖它。这常常导致一个令人困惑的问题：你修改了环境变量或CMakeLists.txt，但重新配置后似乎没生效。

解决方案：

最彻底：直接删除build目录，从头开始配置。
修改缓存变量：在命令行中使用-D选项，如cmake -DCMAKE_PREFIX_PATH=/new/path ..。这会覆盖缓存中的值。
使用CMake GUI或ccmake工具：它们可以交互式地查看和修改所有缓存变量。

5.3 目标属性传递性的正确理解：PUBLIC， PRIVATE， INTERFACE

这是现代CMake最核心也最容易用错的概念。

PRIVATE：属性只应用于当前目标本身。比如，target_compile_options(my_lib PRIVATE -Wall)，那么只有my_lib在编译时会加上-Wall选项，链接my_lib的其他目标不会继承这个选项。
PUBLIC：属性既应用于当前目标，也传递给任何链接它的目标。比如，target_include_directories(my_lib PUBLIC include)，那么my_lib和所有链接my_lib的目标在编译时都能找到include目录。
INTERFACE：属性不应用于当前目标本身（可能因为它是一个接口库，没有源文件），但会传递给任何链接它的目标。比如，你创建一个纯头文件库的目标，就可以用INTERFACE来设置头文件路径。

一个常见的错误：为一个静态库目标A用PUBLIC链接了另一个库B，而A的源代码其实并没有使用B的任何符号，只是A的头文件中包含了B的头文件。这时，应该使用target_link_libraries(A INTERFACE B)，因为对A的编译过程来说，B不是必需的（A.cpp没用到B），但对任何包含A头文件的用户来说，B是必需的。如果用PUBLIC，会导致A在编译时也去查找B，可能在不必要的地方引入依赖或编译错误。

5.4 处理动态库的路径问题（RPATH）

在Linux/macOS上，运行一个链接了动态库的可执行文件时，系统需要知道去哪里找这些.so或.dylib文件。除了标准的系统路径（如/usr/lib），CMake可以通过设置RPATH（运行时搜索路径）来让程序在构建目录或安装目录下直接找到库。

# 在根CMakeLists.txt中设置，让构建出的可执行文件在$ORIGIN/../lib（即相对于可执行文件位置的../lib）下寻找库 # 这对于在build目录内直接运行测试程序非常有用 set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE) set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib") set(CMAKE_BUILD_RPATH ${CMAKE_INSTALL_RPATH}) # 构建时也使用相同的RPATH # 更精细的控制：只为特定目标设置RPATH set_target_properties(my_app PROPERTIES INSTALL_RPATH "$ORIGIN/../lib" BUILD_WITH_INSTALL_RPATH TRUE # 构建时就用安装时的RPATH，方便测试 )

在Windows上，对应的概念是DLL搜索路径，通常将DLL放在与可执行文件相同的目录即可，CMake默认会帮你处理。

5.5 调试CMake：当构建不按预期工作时

CMake脚本出问题时，调试起来可能比调试C++代码还头疼。以下是一些有用的工具和技巧：

message()命令：这是最直接的打印调试信息的方法。你可以打印变量的值。

message(STATUS "Current source dir: ${CMAKE_CURRENT_SOURCE_DIR}") message(WARNING "This library was not found: ${SomeLib}") message(FATAL_ERROR "Critical error, stopping.") # 会终止配置过程

--trace和--trace-expand选项：在运行cmake时加上这些选项，可以输出极其详细的执行过程，包括每一行被执行的命令和变量展开后的值。这对于理解复杂的生成器表达式或追踪变量传递非常有用，但输出量巨大，建议重定向到文件。
```
cmake -S . -B build --trace-source=CMakeLists.txt 2>&1 | tee trace.log
```
检查生成的构建文件：CMake生成的是中间文件（如Makefile、.vcxproj）。直接去build目录下查看这些生成的文件，看看包含路径、链接库、编译选项是否如你所愿。这是验证CMake脚本是否正确工作的最终手段。
使用cmake --graphviz=graph.dot：这个命令会生成一个项目依赖关系的Graphviz图（.dot文件），你可以用dot命令将其转换为图片。这能帮你可视化所有目标（库、可执行文件）之间的依赖关系，检查是否有循环依赖或错误的依赖传递。

构建大型C/C++项目就像指挥一个交响乐团，而CMake就是那位总指挥。它不直接演奏乐器（编译代码），但它确保每个乐手（编译器、链接器）在正确的时间、用正确的乐谱（编译选项、源文件）、与其他乐手协调一致（依赖管理），最终奏出和谐的乐章（可执行程序）。从简单的单文件项目到横跨多个平台、包含数百万行代码的复杂系统，CMake通过其声明式的语法和强大的生成能力，提供了一套统一、可扩展的解决方案。虽然它的学习曲线不低，文档有时也显得晦涩，但一旦掌握其核心思想——围绕“目标”进行声明式管理，你就能极大地提升C/C++项目的构建效率和可维护性，真正实现“一次编写，到处构建”。

查看全文

http://www.cnnetsun.cn/news/4167271.html