SSL的个人Blog - 随笔

git工具使用总结

2025-06-30T00:00:00+08:00

1. git仓库创建

1.1 本地创建并推送

git init
git remote add origin <your-ssh-or-https-url>

git branch -M <branch-name>         # 推荐将分支名称设置为与origin一致
echo "hello world" > README.md      # 替换成你实际对工作区的操作
git add .                           # 添加到暂存区
git commit -m "your commit message" # 将展存区的内容添加到本地存储库 
git push -u origin <branch-name>    # 将当前分支推送到远程仓库，推荐本地和远程之间的分支名称一致

注意：

本地创建仓库的默认名称为master，git branch -M操作是强制对一个分支进行重命名，等同于git branch --move --force操作。
在执行git remote 和git push操作之前，需要保证远程仓库已经建立完成。

1.2 远程创建并`clone`

更加推荐的一种方法，可以直接在github或者gitee等平台上创建仓库，然后通过git clone命令完成clone操作。

git clone <your-ssh-or-https-url>

使用这种方式，可以保证你仓库的分支名称、和远程仓库的关联关系等保持一致。

2. 本地代码存储逻辑

2.1 工作区遇到的问题

试想一下，你对工作区中的内容作了某些修改，但是你发现修改的内容并不能修复你目前存在的问题，你想将修改的部分删除掉，应该怎么做呢？

git restore <file>  # 对单独的某个文件做修改后的恢复操作
git restore .       # 对整个工作区中产生修改的所有文件进行恢复操作

假设在工作区中，你新建了某个文件，但是发现这个文件貌似没有起到什么作用，但恰好你不知道如何那个文件需要被删除，这里提供两种解决方案：

使用git status查看当前工作区状态，在未跟踪部分找到新建的文件，然后使用系统文件管理功能针对性的删除文件。
使用命令行的方式实现删除操作，当然是在清除需要删除的文件之后执行。

git clean -f <file> # 删除某个文件
git clean -df <dir> # 删除某个目录，递归删除

下面是git clean命令常见的参数：

-f：强制删除
-i：在可交互模式下删除
-d：对于某个文件夹，递归的删除

2.2 暂存区存储问题

我认为对于暂存区出现的任何问题都可以通过直接修改当前工作区，然后通过git add命令添加到暂存区解决。不过这里我还是贴出某些问题的命令行解决方法：

工作区添加到暂存区的方法

git add <file>  # 添加新文件或文件修改到暂存区
git add .       # 添加所有更改和新创建文件到暂存区

添加到暂存区后,出现问题,如何修改?

git reset <file>    # 撤销某个指定文件的暂存区的更改
git reset .         # 撤销暂存区的所有更改

2.3 本地版本库存储问题

当团队组合开发某个应用功能时，需要创建新分支，然后当某个分支合并完成后，需要将一个分支进行删除时应该如何操作呢？

git checkout -b <new-branch-name>           # 以当前HEAD指向的commit为起始点，创建并切换到分支下
git branch <new-branch-name> <commit>       # 以某次提交为起始点，创建分支，不切换
git branch <new-branch-name> <branch-name>  # 以branch指向的commit为起始点，创建分支，不切换
git branch <new-branch-name> <tag-name>     # 以某个tag指向的commit为起始点，创建分支，不切换
git branch -d <branch-name>                 # 删除某个分支

有一种比较清晰的branch管理方法，即使用name/task的命令方式，name对应实际的人名，而task代表这个人在这个分支下需要完成的人物，这样比较清晰明了，并且当其完成某个任务后，可以为这个分支打上一个name/task的tag标签这么作有以下两个好处：

当task没有完成时，分支跟着commit向前滚动，可以明确当前时间下，哪个人员在作哪些事情。
当task完成后，可以将最终的commit标记为一个tag，做到工作留痕，并可以在未完成时（经过市场验证，发现解决的不是特别好），可以根据这个tag回滚，继续完善这个任务。

当团队协作过程中，某个人在name/task分支下，完成了功能开发以后，经测试没问题，进行向主分支合并时，或许会遇到一些问题：

当main分支指向的提交为name/task指向提交的直接祖先时，git默认会采用fast forward策略，不创建提交，而是直接将main指向name/task指向的提交。
当name/task分支在解决问题，不断的创建提交的过程中，main分支也在不断的被更新创建提交时，会出现以下两种情况：
当分支name/task和main同时拥有的文件没有发生改变时，将无冲突发生，git merge会默认合并到main分支中去，中间会创建新的commit。
当分支name/task和main同时拥有的文件同时发生了修改时，将有冲突发生，git merge会将冲突产生的文件里面的内容进行标记，并放在暂存区，等待用户解决。
当git merge命令可以自己合并分支时，如果产生了提交，git merge会自动生成提交语句，如果用户想自定义这个提交应该怎么解决？使用下面的命令即可解决这个问题。

git merge --no-commit <name/task> # 前提保证目前HEAD指向的是main分支

代码里面，--no-commit参数代表的意思是不需要默认提交，而是将修改放到暂存区，等到用户边界提交内容后，再统一提交。
当存在冲突时，--no-commit没有任何作用，因为冲突需要用户手动处理，不会默认提交。

当你刚提交完某个commit到本地后，发现comment content并不满意，无法体现你所做工作的内容，因此你想修改这个提交内容，应该怎么做呢？下面是解决思路：

git reset --soft HEAD^ # 将当前分支回退到commit之前
git add .
git commit -m "<your-new-commit-conten>"

注意：

--soft表示不删除工作区文件，退回到指定commit之后，工作区的内容并没有发生修改
保证最近提交没有同步到远程仓库，否则reset后，提交到远程仓库会失败

2.4 提交`commit`的别名`tag`

经常逛github的你，肯定会发现，某个存储库，除了使用branch以外，还会有一个名为tag的东西，这是什么？

tag是一个commit的类型别名，当使用某个commit创建了tag后，这个tag就不会随着commit的增加而更新指向了
branch会随着commit的不断更新维护所有的提交，并维护的最后一个commit，这是branch与tag之间最大的区别

git tag <your-tag-name> <commit-hash> -m "<your-tag-desc-message>"  # 以某个commit添加tag
git tag -d <your-tag-name>                                          # 删除tag
git push origin <your-tag-name>                                     # 推送tag到远程仓库

3. 远程仓库存储逻辑

3.1 本地与远程的同步操作

远程到本地的同步操作：

# 存储库同步操作
git clone <your-remote-repo-url>    # 本地向远程同步所有存储库内容

# 分支同步操作
git pull                            # 从远程仓库中拉取merge所有更新(tag、branch、commit)
git pull origin <your-branch-name>  # 同步指定分支，拉取并merge，同名分支
git pull origin <remote-branch>:<local-branch> # 拉取并merge指定分支，不同名分支(不推荐)

git fetch                           # 从远程仓库中拉取所有更新，但不merge
git fetch origin <your-branch-name> # 拉取指定分支，不merge，同名分支
git fetch origin <remote-branch>:<local-branch> # 拉取指定分支，不merge，不同名分支(不推荐)

# tag同步操作
git pull origin --tags                              # 同步指定分支
git pull origin <tag-name>                          # 同步指定tag，并且tag重名
git pull origin <remote-tag-name>:<local-tag-name>  # 同步指定tag，并且tag不同名

本地到远程的同步操作：

# 分支同步操作
git push                        # 当前HEAD指向的分支
git push origin <brach-name>    # 推送指定分支到origin，同名
git push origin <local-branch-name>:<remote-branch-name> # 推送local-branch，不同名

git push origin <tag-name>      # 推送指定tag，同名
git push origin <local-tag-name>:<remote-tag-name> # 推送local-tag，不同名
git push origin --tags          # 推送所有tag

git push --delete origin <branch-name>  # 删除远程分支操作
git push --delete origin <tag-name>     # 删除远程tag

3.2 远程冲突的解决

远程冲突的发生，往往是因为直接使用git pull或者git merge操作时，导致的冲突，原因都可以归结为git merge操作，解决远程冲突与本地冲突一样，详情间2.3本地合并的冲突问题。

4. 其他内容

4.1 gitignore和gitattributes和gitsubmodule

.gitignore文件定义了工作区间内，什么的文件或者文件夹不因该被git所管理。对于C++的项目来讲，build文件夹下的编译内容不应该被管理，.idea下的IDE配置不应该被管理等等。此外，.gitignore文件还支持正则表达式匹配。下面就是一个C++项目的.gitignore文件。

# 不同平台下，源文件编译生成的二进制文件
*.slo
*.lo
*.o
*.obj

# 预编译的头文件
*.gch
*.pch

# 编译的动态库文件
*.so
*.dylib
*.dll

# 编译的静态库文件
*.lai
*.la
*.a
*.lib

# 编译的可执行文件
*.exe
*.out
*.app

# 编译中间文件的文件夹
build/

# IDE生成的文件
.vscode/

# 可自行文件的文件夹
bin/

# 库文件文件夹
lib/

注意，对于不同分支下，可能会存在不同的ignore操作，比如分支a里面使用了ros2完成了某项功能，而分支b使用ros完成了某项功能，两个分支.gitignore应该都需要忽略ros项目的build devel log编译文件夹和ros2项目的build install logs文件夹，这种情况下，两分支下的.gitignore应该保持一致，避免在切换分支时的误添加操作。

.gitattributes文件主要有以下说明：

行尾符处理，不同的操作系统，对换行符的理解存在差异，可以指定某些系统强相关的文件指定换行符为特定符号，例如指定*.bat和*.cmd结尾的windows脚本文件以crlf结尾，而其余文件指定lf为结尾，而对于可跨平台的文本文件，则在IDE指定换行符即可。
merge规则指定，对于不同的文件，需要指定不同的合并规则，例如*.md，*.cpp等文本文件，应该使用merge=text策略，将内容差异拼接到工作空间的对应文件夹中，进行人为的修改合并即可。而对于binary文件，其并不会像text文本文件那些将内容拼接，而是等待用户自行修改，可以选择传入新的文件，也可以使用git checkout --ours或者git checkout --theirs来选择当前HEAD或者其他commit中的文件。
文件归档控制，git archive命令可以输出归档后的源文件信息，而某些文件不需要出现在源文件中，例如.gitattributes文件，.gitignore文件，文档文件夹，测试文件夹等都不需要归档打包，因此在.gitattributes文件中，可以使用export-ignore关键字进行声明；

一个比较成熟的项目.gitattributes文件如下：

# 行尾符处理
* text=auto
*.txt text
*.md text
*.cpp text
*.h text
*.py text eol=lf
*.sh text eol=lf

# windows脚本文件行尾说明
*.bat text eol=crlf
*.cmd text eol=crlf

# 二进制文件，即当merge时，采用binary合并策略
*.png binary
*.jpg binary
*.pdf binary
*.exe binary

# 合并策略声明
*.conf merge=union

# 归档控制 - 排除开发相关文件
.gitignore export-ignore
.gitattributes export-ignore

# 归档控制 - 排除测试和文档目录
tests/ export-ignore
docs/ export-ignore
examples/ export-ignore

# 归档控制 - 排除构建相关目录
*.log export-ignore

export-ignore在归档时，控制着commit中忽视的内容
git archive -o xxx/xxx.tar.gz [commit]，会查看.gitattributes文家里面有关的归档操作。
.gitattributes文件里面的等号相连之间不能存在空格，否则为非法，就像json文件里面不能使用单引号表示字符串一样。

.gitsubmodules文件用于管理项目下的子模块,其主要在以下几种情况下比较有用:

当子模块和当前项目都是你们自己团队的任务时,你们可以同时对子模块和当前项目进行开发;
当子模块为项目依赖的某个开源三方库时,使用子模块操作,可以减少当前项目占用的仓库空间;

为项目添加一个现有的子模块,可以使用下面的命令实现:

git submodule add -b <branch-name> -- <url> <path>

branch-name为模块依赖的分支名称
url为模块对应的远程仓库地址
path为模块在项目工作空间存放的路径位置

当添加了某个子模块后,应该如何删除呢?

git submodule deinit -- <path> # 取消子模块与当前工作区间的关联
rm -rf .git/modules/<path>     # 删除.git下对于子模块的存储逻辑
nano .gitmodules               # 针对性的处理.gitmodules文件,对相关模型进行删除

当模块中的内容发生改变时,项目和子模块如何使用git进行管理呢?

cd <submodule-path>
git add .
git commit =m "<module-commit-message>"
cd <project-path>
git add .
git commit -m "<project-sync-module-message>"
git push   # 同步更新子模块远程仓库和项目远程仓库

当clone某个带有子模块的项目时,应该同步clone它的子模块呢?

git clone <project-with-submodule>
git submodule update --init --recursive

--init 初始化子模块和项目关联
--recursive 递归的处理所有子模块下的子模块

4.2 diff操作查看文件差异

git diff <commit>          # 查看工作区和某次commit之间的差异
git diff --staged <commit> # 查看暂存区和某次commit之间的差异，默认为HEAD
git diff <commit-a> <commit-b> -- file # 查看两个commit之间的file差异
git diff <commit-a> <commit-b>         # 查看两个commot之间所有文件差异

针对两个commit之间的差异，<commit-a>为原始commit而<commit-b>为修改commit，相当于查看<commit-b>相比与<commit-a>之间修改了什么内容。
--stat可选参数可以输出统计信息，即显示某个文件修改的行数，可以快速查看那些文件作了多少的修改，比较直观。

4.3 log操作查看某次提交的提交记录

当直接使用git log时，会将HEAD指向的commit对应的所有父级（包含其本身）对应的commit对应的hash值和commit content内容打印出来（包括时间、作者和邮箱信息）。
注意，这里的父级不仅包含同一branch下的commit关系，还包含了merge后，merge节点对应的commit的父子关系。
当git log <commit/branch/tag>时，对应的都是其指向的commit对应的所有父级（包含其本身）的commit节点信息。

4.4 团队合作谨用rebase操作

git rebase 一个比较危险的操作，它最普通的用法是可以将某个branch的所有commit的父commit转换到指定的commit下，也叫做branch的换基操作。
此外，交互式rebase操作通过-i选项打开，通过指定某个commit，对其子commit进行统一的修改操作
edit，对某个commit提交的内容不满意，可以对这个commit进行针对性的修改，然后使用git rebase --continue继续
reword，对某个commit提交的commit message进行修改
squash，对多个commit操作执行合并操作
fix-up，对多个commit合并但丢弃提交信息
drop，删除提交，或者直接在交互界面删除某行即可。
注意，git rebase操作会在指定的upstream的基础上，生成新的commit，新生成的commit的commit hash发生了改变，因此当向远程推送时，远程仓库无法执行fast forward的合并操作，会导致推送失败。因此当团队合作开发时，请谨慎使用git rebase。

如何使用cmake构建一个自定义的可安装的库呢？

2025-03-01T00:00:00+08:00

背景

我觉得所有学习过某种编程语言的人，或多或少都希望自己构建一个可使用标准化流程安装的三方库。当然我也不例外，我平时的大部分精力都会放在SLAM的学习上，我的想法是做一个简单方便的SLAM可视化小工具，用来帮助自己快速验证一个SLAM算法的效果和可行性。几个月前，我确实把一个名为SLAM_VIEWER的小工具开源了出来。为了方便自己也是为了方便大家的使用，我希望我写的三方库可以像主流的三方库一样，能够使用一个标准化的编译和安装流程，并能够在cmake中很方便地导入使用。在我查阅了cmake官方文档并奴役了许多AI后，得到了一套流程化的解决方案：

解决方案

# CMakeLists.txt

cmake_minimum_required(VERSION 3.5)

project(slam_viewer VERSION 0.0.2)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
if(NOT CMAKE_BUILD_TYPE)
    set(CMAKE_BUILD_TYPE Release)
endif()

if(NOT DEFINED BUILD_EXAMPLES)
    set(BUILD_EXAMPLES ON)
endif()

find_package(Pangolin REQUIRED)
find_package(Sophus REQUIRED)
find_package(PCL REQUIRED)
find_package(TBB REQUIRED)
find_package(OpenCV REQUIRED)
find_package(Eigen3 REQUIRED)

set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/bin)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/lib)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}/lib)
set(PACKAGE_INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/include)
set(PACKAGE_LIBS_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/lib)

include_directories(${CMAKE_CURRENT_SOURCE_DIR}/include)

file(GLOB SRC_FILES ${CMAKE_CURRENT_SOURCE_DIR}/src/*.cc)

add_library(slam_viewer SHARED ${SRC_FILES})
target_link_libraries(
    slam_viewer PUBLIC ${Pangolin_LIBRARY} ${PCL_LIBRARIES} Sophus::Sophus
                       TBB::tbb ${OpenCV_LIBS} Eigen3::Eigen)
target_include_directories(
    slam_viewer PUBLIC ${OpenCV_INCLUDE_DIRS} ${PCL_INCLUDE_DIRS}
                       $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
                       $<INSTALL_INTERFACE:include>)

if(${BUILD_EXAMPLES})
    add_subdirectory(examples)
endif()

# 添加安装指令
install(
    TARGETS slam_viewer
    EXPORT ${PROJECT_NAME}Targets
    LIBRARY DESTINATION ${PACKAGE_LIBS_INSTALL_DIR}
    ARCHIVE DESTINATION ${PACKAGE_LIBS_INSTALL_DIR})
install(DIRECTORY ${PROJECT_SOURCE_DIR}/include/slam_viewer
        DESTINATION ${PACKAGE_INCLUDE_INSTALL_DIR})

# 安装导出文件
install(
    EXPORT ${PROJECT_NAME}Targets
    FILE ${PROJECT_NAME}Targets.cmake
    NAMESPACE ${PROJECT_NAME}::
    DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/cmake/${PROJECT_NAME})

# 生成并安装Config文件
include(CMakePackageConfigHelpers)
write_basic_package_version_file(
    ${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
    VERSION ${PROJECT_VERSION}
    COMPATIBILITY SameMajorVersion)

configure_file(Config.cmake.in
               "${PROJECT_BINARY_DIR}/${PROJECT_NAME}Config.cmake" @ONLY)

install(FILES ${PROJECT_BINARY_DIR}/${PROJECT_NAME}Config.cmake
              ${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
        DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/cmake/${PROJECT_NAME})

# 输出配置信息，以查看是否配置正确
message(====================================================================)
message(STATUS ${PROJECT_NAME} Configure:)
message(STATUS CMAKE_BUILD_TYPE: ${CMAKE_BUILD_TYPE})
message(STATUS BUILD_EXAMPLES: ${BUILD_EXAMPLES})
message(STATUS CMAKE_INSTALL_PREFIX: ${CMAKE_INSTALL_PREFIX})
message(====================================================================)

上面的cmake代码是我根据这一套流程配置的slam_viewer库，其主要涵盖以下几个方面的内容：

1. 安装Targets和头文件目录

install(TARGETS slam_viewer
        EXPORT ${PROJECT_NAME}Targets
        LIBRARY DESTINATION ${PACKAGE_LIBS_INSTALL_DIR}
        ARCHIVE DESTINATION ${PACKAGE_LIBS_INSTALL_DIR})
install(DIRECTORY ${PROJECT_SOURCE_DIR}/include/slam_viewer
        DESTINATION ${PACKAGE_INCLUDE_INSTALL_DIR})

install是cmake中比较常用的一个命令，其作用主要是将某个文件夹，某个文件或者某些Target安装到指定的位置。如果你需要安装的是某个目录，就需要使用DIRECTORY关键字，并在后面跟上待文件夹的位置，然后使用DESTINATION关键字来指定安装的位置。在标准工作流程里面，使用安装文件夹的命令，将头文件目录安装到${PACKAGE_INCLUDE_INSTALL_DIR}位置，其中${PACKAGE_INCLUDE_INSTALL_DIR}=${CMAKE_INSTALL_PREFIX}/include，如果不指定CMAKE_INSTALL_PREFIX的话，默认为/usr/local。

使用install将TARGETS安装到某个位置时就比较繁琐了，首先需要指定TARGETS关键字，并在后面跟上需要安装的target的名称（在cmake中，可执行文件，库文件都是以TARGET的形式维护）。EXPORT关键字代表需要生成一个TARGETS相关的依赖文件，这个依赖文件就是${PROJECT_NAME}Targets.cmake。里面维护了TARGETS中的依赖关系，主要有两个内容，一个是INTERFACE_LINK_LIBRARIES，另一个是INTERFACE_INCLUDE_DIRECTORIES。

INTERFACE_LINK_LIBRARIES维护的是TARGET所有依赖的动态库的TARGET名字，这部分是通过解析target_link_libraries指令内容生成的。
INTERFACE_INCLUDE_DIRECTORIES维护的是TARGET所有依赖的头文件的路径，这部分是通过解析target_include_directories指令内容生成的。
当然，只有使用PUBLIC和INTERFACE关键字指定的依赖才会被解析并放在INTERFACE_LINK_LIBRARIES和INTERFACE_INCLUDE_DIRECTORIES中。
这里并不会对PUBLIC、INTERFACE和PRIVATE关键字进行解析，网上也有很多这方面的资料可以参考。

下面是slam_viewerTargets.cmake文件的部分截图，这部分内容相当重要，或者中可以通过这个xxxTargets.cmake文件来找到三方库的Target信息，并且可以明确这个Target的依赖关系。

2. 安装导出的Target依赖文件到指定位置

install(EXPORT ${PROJECT_NAME}Targets
        FILE ${PROJECT_NAME}Targets.cmake
        NAMESPACE ${PROJECT_NAME}::
        DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/cmake/${PROJECT_NAME})

这一步主要是为了将Target的依赖文件和slam_viewerConfig.cmake文件导出到同一目录下方便slam_viewerConfig.cmake文件的引用include()操作。根据cmake官方文档部分的说明，安装TARGET的依赖文件必须使用带有EXPORT关键字的安装命令，并且EXPORT关键字后面与安装TARGETS的EXPORT关键字后面的内容保持一致，FILE关键字后指定安装文件的文件名。NAMESPACE关键字是一个可选的参数，如果带有NAMESPACE，那么在其他依赖当前编译的三方库文件时，就需要在Target名字前指定命名空间，在上面slam_viewerTargets.cmake文件的部分截图中也能体现。在一定程度上，可以防止同名TARGET的出现。

3. 生成并安装配置文件

include(CMakePackageConfigHelpers)
write_basic_package_version_file(
    ${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
    VERSION ${PROJECT_VERSION}
    COMPATIBILITY SameMajorVersion)

configure_file(Config.cmake.in "${PROJECT_BINARY_DIR}/${PROJECT_NAME}Config.cmake" @ONLY)

install(FILES ${PROJECT_BINARY_DIR}/${PROJECT_NAME}Config.cmake
              ${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake
        DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/cmake/${PROJECT_NAME})

首先需要引入CMakePackageConfigHelpers模块，需要这个模块的write_basic_package_version_file函数来写版本配置文件xxxConfigVersion.cmake。其中VERSION关键字后面跟项目版本号，COMPATIBILITY关键字后面指定版本兼容信息，这里的版本兼容性可以为后续find_package提供信息。一共有AnyNewerVersion|SameMajorVersion|SameMinorVersion|ExactVersion这四种版本兼容要求，其详细的内容解释可以看cmake文档。

configure_file函数配置xxxConfig.cmake文件，当我们使用find_pacakge(xxx)函数来查找xxx三方库时，find_package函数会试图找到一个xxxConfig.cmake或xxxConfigVersion.cmake文件来判断是否找到了xxx库。代码中Config.cmake.in为配置source文件路径，而"${PROJECT_BINARY_DIR}/${PROJECT_NAME}Config.cmake"为配置target文件路径，其中@ONLY限定了替换的变量只能用@符号包裹起来。configure_file函数的一些实例内容解释可以看cmake文档。

最后安装xxxConfig.cmake和xxxConfigVersion.cmake文件到指定位置即可。这个位置建议和xxxTargets.cmake的安装位置保持一致。

4. 配置Config.cmake.in文件

# Config.cmake.in

include(CMakeFindDependencyMacro)

find_dependency(Pangolin REQUIRED)
find_dependency(Sophus REQUIRED)
find_dependency(PCL REQUIRED)
find_dependency(TBB REQUIRED)
find_dependency(OpenCV REQUIRED)
find_dependency(Eigen3 REQUIRED)

include("${CMAKE_CURRENT_LIST_DIR}/@PROJECT_NAME@Targets.cmake")

最后需要配置Config.cmake.in文件，在第3步中，configure_file函数将Config.cmake.in文件配置到${PROJECT_BINARY_DIR}/${PROJECT_NAME}Config.cmake文件中，其中@PROJECT_NAME@为PROJECT_NAME变量，${CMAKE_CURRENT_LIST_DIR}为当前xxxConfig.cmake文件所在的目录。也就是为什么第3步的结尾建议要和xxxTargets.cmake的安装装位置保持一致，如果不一致，这里include()参数路径就需要更改。

除此之外，还需要对自定义的三方库依赖的三方库进行配置，这里需要使用find_dependency函数，而find_dependency函数在模块CMakeFindDependencyMacro中定义。配置好find_dependency后，当其他库文件或者可执行文件依赖当前定义的库文件时，就不需要对自定义的三方库依赖的三方库进行find_package操作了。

5. 配置依赖自身的头文件路径的INTERFACE_INCLUDE_DIRECTORIES

target_include_directories(
    slam_viewer PUBLIC ${OpenCV_INCLUDE_DIRS} ${PCL_INCLUDE_DIRS}
    $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
    $<INSTALL_INTERFACE:include>
)

在讲解这里的用法之前，我们需要理清楚一个比较重要的问题：

在源码中可以看到，对某些库文件，没有使用include_directories或者target_include_directories明确指定它们的头文件路径，而有些库像OpenCV和PCL都需要在CMakeLists.txt中明确指定头文件路径。在第一部分讲到，如果你在target_include_directories中指定了某些头文件路径，那么在导出的含有依赖关系的文件xxxTargets.cmake中会有一个INTERFACE_INCLUDE_DIRECTORIES，这里会维护这个Target依赖的头文件路径。当某些库严格按照target_include_directories来维护Target的依赖关系时，导出的xxxTargets.cmake文件中必然保存着该Target依赖的所有头文件路径，因此这种库只需要使用target_link_libraries函数即可搞定头文件依赖和库文件依赖关系。然而总有些三方库因为这样或者那样的原因，选择不使用target_include_directories来维护头文件依赖关系，这种库往往都会提供一个xxx_INCLUDE_DIRS这个变量，供调用者使用，因此遇到这种三方库依赖时，需要将target_include_directories来单独维护这份头文件依赖，然后导入到自身的INTERFACE_INCLUDE_DIRECTORIES中。

我相信通过上面一段阐述的内容，同学们应该能理解为什么OpenCV和PCL库需要单独使用target_include_directories来维护头文件依赖关系，而其他库则不需要。除此之外，$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>和$<INSTALL_INTERFACE:include>这两个内容应该吸引了你的注意。根据cmake官方文档的解释，以$<BUILD_INTERFACE:开头的内容是声明构建过程中所需要的头文件依赖关系，并且后面需要跟绝对路径，而以$<INSTALL_INTERFACE:开头的内容则是安装过程中的头文件依赖或者使用的头文件依赖，后面需要跟以 ${CMAKE_INSTALL_PREFIX}$ 为前缀的相对路径。在xxxTargets.cmake中会忽略$<BUILD_INTERFACE:开头的头文件依赖。而没有$<开头的CMAKE会认定这种头文件依赖发生在编译和安装使用过程，因此也会在xxxTargets.cmake中保存下来。

6. 如何使用？

根据上面的解释，我们不难理解所有的库文件依赖关系都在xxxTargets.cmake维护的INTERFACE_LINK_LIBRARIES中，而所有的头文件依赖关系都在xxxTargets.cmake维护的INTERFACE_INCLUDE_DIRECTORIES中，而在xxxConfig.cmake中使用find_dependency代替了find_package函数来导入依赖库文件的Target。因此使用自定义的slam_viewer库时，只需要使用下面的两行代码就可以搞定，可以说非常的简单：

# your project CMakeLists.txt

find_package(slam_viewer REQUIRED)

target_link_libraries(<your_target> slam_viewer::slam_viewer)

标准流程？

上面的内容，是我自己在看了网上的教程和一些通用三方库的CMakeLists.txt总结来的一套适合我自己使用的建库流程，当然这并不是唯一的建库方法。cmake官方教程的step9-step11也是非常好的建库流程。我想说的是，无论使用什么样的方式，只要能实现一般三方库导入项目的功能，就是一个好的标准流程。我也非常希望我写的东西能对你有所帮助。