3k star 项目 learning-cmake 点评

3k star 项目 learning-cmake 点评

Author: ChrisZZ
Time: 2024.06.17

概要

这次我们分析 github 上搜索 cmake 排名第三的项目 https://github.com/Akagi201/learning-cmake . 第一名是 cmake 源码的镜像, 第二名是上次分析过的 cmake-examples.

从目录结构和 README.md 来看,内容不多,覆盖范围较少,内容简单, 新人应该也可以在第一次看的时候,看懂大部分内容:

LICENSE
README.md
boost
config-file
curl
docs
hello-module
hello-world
hello-world-clear
hello-world-lib
hello-world-shared
hunter-simple

接下来我们逐个目录阅读和点评。

hello-world

C 风格的示例代码。 打印了 PROJECT_BINARY_DIR 和 PROJECT_SOURCE_DIR. 坦白说个人觉得这两个目录应该换成 CMAKE_BINARY_DIR 和 CMAKE_SOURE_DIR, cmake 用户也应该逐渐淡化 project 的概念。 cmake 里的 project 对应到 Visual Studio 里的 solution, 而 Visual Studio 里的 project 对应到 CMake 里的 target, 这不免让初学者迷惑。 而且 modern cmake 强调面向 target , project 相关的变量个人建议少用。

hello-world-clear

“分离了源文件和输出文件”, 这是原作者的说明(的中文翻译), 但是我没看出来哪里有分离。 主要差别是增加了三次 INSTALL() 命令的调用, 安装了文件、程序、目录。

搞得有点过于形式化了, 不够脚踏实地, 应该创建静态库 hello,安装 hello 的库和可执行文件; 或者只安装 hello-world 可执行程序。

hello-world-lib

创建了库目标 hello_static 和 hello_shared, 然后分别执行安装。 本意是好的, 但是同时安装静态库和动态库, 这是给自己增加难度,也重复编译了相同的代码, 很别扭。 建议改造, 要么是在调用 cmake 时候, 通过控制 BUILD_SHARED_LIBS 来控制; 要么是在 CMakeLists.txt 里创建 object 目标,再分别创建静态库和动态库。

curl

这是一个 find_package() 的使用案例。

里面使用 if/else/endif 的写法过于陈旧了,得批评一下。

if(CURL_FOUND)
  include_directories(${CURL_INCLUDE_DIR})
  target_link_libraries(curltest ${CURL_LIBRARY})
else(CURL_FOUND)
  message(FATAL_ERROR "CURL library not found")
endif(CURL_FOUND)

应当改为

if(CURL_FOUND)
  include_directories(${CURL_INCLUDE_DIR})
  target_link_libraries(curltest ${CURL_LIBRARY})
else()
  message(FATAL_ERROR "CURL library not found")
endif()

另外, 指定的 cmake 最小版本竟然是 2.8.4, 去死吧老古董。

cmake_minimum_required(VERSION 2.8.4)

起码应该改为

cmake_minimum_required(VERSION 3.5)

hello-module

展示了使用 FindHELLO.cmake 文件, 来让 find_package(HELLO) 找到包的案例。 这个目录是10年前添加的, 10年过去了, cmake 官方的 cmake tutorial 里竟然都还没有这样的例子。 只能说, 没有最差, 只有更差。

这个目录的写法, 适合初学者了解 find_package 用法中的其中一个情况。 不过这其实仍然是 cmake 官方设计的不太好导致用户要学习的一个糟粕, 实际上目前已经不推荐用户自己写 FindXXX.cmake 了, 推荐写法是用户通过 cmake 生成 xxx-config.cmake 文件, 通过 find_package(xxx CONFIG) 来查询包。

config-file

本意是好的,展示使用 configure_file(), 在 configure 阶段生成 .h 文件, 里面的宏定义也是 configure 阶段生成,供 C/C++ 代码使用。

不太好的地方: 大小写不当。

CONFIGURE_FILE(${CMAKE_MODULE_PATH}/build.h.in ${CMAKE_BINARY_DIR}/build.h)
CONFIGURE_FILE(${CMAKE_MODULE_PATH}/config.h.in ${CMAKE_BINARY_DIR}/config.h)

应该改为

configure_file(${CMAKE_MODULE_PATH}/build.h.in ${CMAKE_BINARY_DIR}/build.h)
configure_file(${CMAKE_MODULE_PATH}/config.h.in ${CMAKE_BINARY_DIR}/config.h)
OPTION( WITH_FOO "Enable FOO support" ON )
OPTION( WITH_BAR "Enable BAR component" OFF )
SET( BAZ 18 )

应该改为

option(WITH_FOO "Enable FOO support" ON)
option(WITH_BAR "Enable BAR component" OFF)
set(BAZ 18)

hunter-simple

介绍了使用 hunter 这个简易的包管理器, 来导入和使用 gtest。

include("cmake/HunterGate.cmake")
HunterGate(
        URL "https://github.com/ruslo/hunter/archive/v0.18.16.tar.gz"
        SHA1 "6cbca2b0e7605ad8ea22ee3527850996436f71b8"
)

实话说这个写法真的挺雷人的, 凭啥要用什么版本的包, 要显式写出 SHA1 呢?作为一个包管理器, 只能说 Hunter 还是过于简陋, 导致用户的代码很丑很难写。

### Download dependencies ###
hunter_add_package(GTest)

### Find dependencies ###
find_package(GTest CONFIG REQUIRED) # GTest::main

这两句中规中矩。

### Targets ###
add_executable(hunter_simple module.cc module_test.cc)
target_link_libraries(hunter_simple PUBLIC GTest::main)

### Testing ###
enable_testing()
add_test(NAME SimpleTest COMMAND hunter_simple)

这些也中规中矩, 不过比 CMake 官方的 CMake Tutorial 里的在 CMakeLists.txt 里写单元测试 case 的写法要靠谱、实用多了。

boost

使用 boost 库的例子. 这位作者可能是写一些服务器后端、网络的选手。

project(boost_demo)
cmake_minimum_required(VERSION 3.0) # 这里应该改用 3.5

find_package(Boost REQUIRED) # 很好, REQUIRED 用对了
include_directories(${Boost_INCLUDE_DIR}) # 糟糕, 应该用 target_include_directories()
link_directories(${Boost_LIBRARY_DIRS}) # 太糟糕! 绝对不能使用 link_libraries(). 会影响后续 target_include_directories() 等
set(Boost_USE_STATIC_LIBS        OFF) # 还行
set(Boost_USE_MULTITHREADED      ON)  # 还行 
set(Boost_USE_STATIC_RUNTIME     OFF) # 还行
set(BOOST_ALL_DYN_LINK           ON) # 还行

add_executable(${PROJECT_NAME} main.cpp) # 可以
target_link_libraries(${PROJECT_NAME} ${Boost_LIBRARIES}) # 还行

总的来说, 对于6年前的 commit, 即使是6年前点评, 也还是凑合,更别提2024年点评了。

总结

这个项目的例子不多, 应该是上传的比较早, 获得的 star 和内容丰富程度以及质量, 并不成比例。

对于 cmake 初学者, 应该可以快速看懂每个目录的内容, 但是不建议效仿, 而是应该问问自己: 这么多糟糕的地方, 自己能看出多少,改进多少?

posted @ 2024-06-17 22:18  ChrisZZ  阅读(13)  评论(0编辑  收藏  举报