【Linux 环境变量相关】深入理解Linux下 CMake、Shell 与环境变量的交互（一）https://developer.aliyun.com/article/1467704
5.3 常见问题与解决方案
5.3.1 命令未找到
当我们在 CMakeLists.txt 中使用 execute_process 命令时，有时可能会遇到 “命令未找到”（Command not found）的错误。这通常是因为命令不在 PATH 环境变量中。为了解决这个问题，我们可以使用 find_program 命令来确保命令的可用性。
find_program(MY_COMMAND NAMES my_command) if(MY_COMMAND) execute_process(COMMAND ${MY_COMMAND} ...) else() message(WARNING "my_command 不在 PATH 中!") endif()
这样，我们就可以确保 my_command 是可用的，或者在它不可用时给出一个警告。
5.3.2 环境变量的问题
当我们在 execute_process 中执行命令时，有时可能会遇到环境变量的问题。例如，我们可能在 ~/.bashrc 中设置了某个环境变量，但在 CMake 中它并不生效。这是因为 CMake 不会读取这些初始化文件。为了解决这个问题，我们可以在 execute_process 命令中明确设置这些环境变量。
execute_process( COMMAND some_command ENVIRONMENT "MY_VARIABLE=value" )
这样，some_command 就会在一个包含 MY_VARIABLE 的环境中执行。
5.4 技术方法对比
| 方法 | 优点 | 缺点 |
execute_process |
直接在 CMake 中执行命令，无需额外的脚本 | 可能需要处理环境变量和路径问题 |
| 外部脚本 | 更灵活，可以包含复杂的逻辑 | 需要维护额外的脚本文件 |
add_custom_command |
在构建阶段执行命令，而不是配置阶段 | 只在构建时执行，可能导致配置问题 |
正如 C++ 名著《Effective C++》中所说：“知道一个事物的名称并不等于理解这个事物。”（Knowing the name of something doesn’t mean you understand it.） - Scott Meyers。同样，知道如何使用 execute_process 并不意味着我们真正理解了它的工作原理和潜在的陷阱。只有深入到底层，我们才能真正掌握这个强大的工具。
而从人的本性来看，我们都希望能够直观地理解和使用工具，而不是盲目地遵循规则。这就是为什么我们需要深入研究每一个细节，确保我们的 CMakeLists.txt 是高效、可靠和易于维护的。
6. 常见问题与解决方案
在编程的世界中，我们经常会遇到各种各样的问题。这些问题可能是由于我们对某些技术的不熟悉，或者是由于某些隐藏的细节导致的。当我们面对这些问题时，我们的大脑会自动地寻找答案，这是人类的本能。正如费曼（Richard Feynman）所说：“我认为我可以安全地说，没有人真正理解量子力学。”编程中的许多问题也是如此，但是通过深入探索，我们可以找到答案。
6.1 为什么在 CMake 中执行的 Shell 脚本可能无法识别某些命令？
当我们在 CMake 中使用 execute_process 命令执行 Shell 脚本时，有时可能会遇到这样的问题：脚本无法识别某些命令，尽管这些命令在我们的终端中是可以正常运行的。
这是因为，当我们在终端中运行命令时，我们的 Shell（例如 bash）会加载一些初始化文件，如 ~/.bashrc 或 ~/.bash_profile，这些文件中可能定义了额外的环境变量或别名。
但是，当我们通过 CMake 执行脚本时，这些初始化文件可能不会被加载，导致脚本无法找到某些命令。
示例：
假设我们在 ~/.bashrc 中添加了以下内容：
alias ll="ls -la"
然后，我们在 CMake 脚本中使用 execute_process 命令执行一个 Shell 脚本，该脚本中包含 ll 命令。由于 ~/.bashrc 没有被加载，脚本将无法识别 ll 命令。
解决方案：
- 使用命令的完整路径，而不是别名。
- 在脚本的开头使用
source命令加载~/.bashrc或其他相关的初始化文件。
6.2 如何确保你的脚本在所有环境中都能正常工作？
编写一个在所有环境中都能正常工作的脚本是一项挑战。我们需要考虑到各种可能的环境差异，并确保我们的脚本对这些差异有足够的容错性。
6.2.1 使用绝对路径
避免在脚本中使用相对路径。相对路径可能会因为脚本的运行位置而改变，导致脚本找不到某些文件或目录。相反，尽量使用绝对路径。
示例：
不要这样写：
cd ../logs
而应该这样写：
cd /home/user/project/logs
6.2.2 检查命令的存在性
在脚本中执行命令之前，先检查该命令是否存在。这可以避免因为某些命令在某些环境中不存在而导致的脚本失败。
示例：
if command -v git >/dev/null 2>&1; then git pull else echo "git 命令不存在，请先安装 git。" fi
6.2.3 使用跨平台的命令和选项
避免使用特定于某个平台或 Shell 的命令和选项。尽量使用那些在大多数环境中都可用的命令和选项。
示例：
不要使用 ls --color=auto（这是一个特定于 GNU ls 的选项），而应该使用简单的 ls 命令。
6.2.4 使用表格总结技术方法的对比
| 方法 | 优点 | 缺点 |
| 使用绝对路径 | 路径明确，不受运行位置影响 | 可能不适用于所有环境 |
| 检查命令的存在性 | 避免因命令不存在而导致的脚本失败 | 增加了脚本的复杂性 |
| 使用跨平台的命令和选项 | 脚本在多数环境中都能正常工作 | 可能牺牲了一些功能性 |
7. 实践：优化 CMakeLists.txt
在编程的世界中，我们经常遇到各种各样的问题，而解决这些问题的方法和技巧往往与我们日常生活中的经验和直觉相吻合。CMakeLists.txt 的优化并不仅仅是为了提高效率，更多的是为了使代码更加清晰、易读和易于维护。
7.1 如何组织和优化你的 CMakeLists.txt
当我们面对一个复杂的项目时，组织和结构化的能力就显得尤为重要。这就好比我们在生活中组织家务事务，一个有条理的家会让我们的生活更加轻松愉快。
7.1.1 使用模块化的方法
将 CMakeLists.txt 分解为多个模块或子目录，每个模块负责一个特定的任务或功能。这样，当你需要修改或添加新功能时，只需关注相关的模块，而不是整个文件。
# 主 CMakeLists.txt add_subdirectory(src) add_subdirectory(tests)
在 src 和 tests 子目录中，你可以有自己的 CMakeLists.txt 文件，专门处理那部分的构建逻辑。
7.1.2 避免全局变量
全局变量可能会导致意想不到的副作用，这与我们在生活中遇到的突发情况类似。最好使用 set() 命令的 PARENT_SCOPE 选项来明确地传递变量。
set(MY_VAR "value" PARENT_SCOPE)
7.2 使用 find_program 命令确保命令的可用性
当我们在生活中寻找某样东西时，我们总是希望能够轻松地找到它。同样，在 CMake 中，我们也需要确保所需的程序或库是可用的。
使用 find_program 可以帮助我们找到所需的程序，并在未找到时给出明确的错误消息。
find_program(GIT_EXECUTABLE NAMES git) if(NOT GIT_EXECUTABLE) message(FATAL_ERROR "git 未找到!") endif()
这样，当 git 程序不存在时，CMake 会给出一个明确的错误消息，指导用户如何解决问题。
7.3 从底层源码讲述原理
当我们想要深入了解某个问题时，我们往往会从根本原因开始分析。同样，在 CMake 中，为了真正理解其工作原理，我们需要深入到其底层源码。
例如，add_executable 命令背后的原理是什么？它是如何将源文件编译成可执行文件的？为了回答这些问题，我们可以查看 CMake 的源代码，特别是 cmAddExecutableCommand.cxx 文件。
此外，我们还可以使用以下表格来总结和比较 CMake 中的一些方法：
| 方法 | 用途 | 示例 |
add_executable |
添加一个可执行目标 | add_executable(my_app main.cpp) |
add_library |
添加一个库目标 | add_library(my_lib my_lib.cpp) |
target_link_libraries |
指定目标需要链接的库 | target_link_libraries(my_app my_lib) |
在编程中，我们经常需要做决策和选择。这就像在生活中，我们面临的各种选择。通过深入了解每个选项的底层原理，我们可以做出更明智的决策。
8. 结论
8.1 环境变量管理的最佳实践
环境变量（Environment Variables）是操作系统中用于存储配置信息的全局变量。在 C/C++ 和嵌入式编程中，正确地管理和使用这些变量是至关重要的。
8.1.1 明确的路径设置
当我们谈论 PATH 这样的环境变量时，一个常见的错误是不明确地设置它。例如，假设我们有一个工具 toolA，它依赖于另一个工具 toolB。如果 toolB 不在 PATH 中，toolA 可能会失败。
示例：
export PATH=$PATH:/path/to/toolA:/path/to/toolB
这样，无论在哪里调用 toolA，它都可以找到 toolB。
8.1.2 避免过度依赖全局环境变量
全局环境变量很方便，但过度依赖它们可能会导致问题。例如，如果两个应用都需要同一个库，但版本不同，这可能会导致冲突。
示例：
#include <library.h> // 使用 library 的功能
如果 library 有多个版本，我们应该明确指定我们需要哪个版本，而不是依赖于全局设置。
8.1.3 使用局部环境变量
在某些情况下，使用局部环境变量而不是全局变量可能更有意义。这可以确保我们的应用在不同的环境中都能正常工作。
示例：
export LOCAL_VAR=value ./my_app
在这里，LOCAL_VAR 只在 my_app 的上下文中存在。
8.2 CMake 和 Shell 的正确结合方式
CMake 和 Shell 都是强大的工具，但将它们结合使用时，我们需要注意一些事情。
8.2.1 使用 execute_process 的注意事项
当使用 execute_process 在 CMake 中调用 Shell 命令时，我们应该确保我们的命令不依赖于任何特定的环境设置。
示例：
execute_process(COMMAND my_command)
在这里，my_command 应该是一个完整的命令，不依赖于任何外部设置。
8.2.2 明确的依赖关系
确保你的 CMakeLists.txt 中的所有命令都有明确的依赖关系。这样，当你的项目变得复杂时，你可以避免潜在的问题。
示例：
add_executable(my_app main.cpp) target_link_libraries(my_app my_library)
在这里，我们明确指定了 my_app 依赖于 my_library。
8.2.3 避免硬编码路径
在 CMakeLists.txt 中，避免硬编码路径。这可以确保你的项目在不同的机器和环境中都能正常工作。
示例：
find_package(MyLibrary REQUIRED)
使用 find_package 而不是硬编码库的路径。
结语
在我们的编程学习之旅中，理解是我们迈向更高层次的重要一步。然而，掌握新技能、新理念，始终需要时间和坚持。从心理学的角度看，学习往往伴随着不断的试错和调整，这就像是我们的大脑在逐渐优化其解决问题的“算法”。
这就是为什么当我们遇到错误，我们应该将其视为学习和进步的机会，而不仅仅是困扰。通过理解和解决这些问题，我们不仅可以修复当前的代码，更可以提升我们的编程能力，防止在未来的项目中犯相同的错误。
我鼓励大家积极参与进来，不断提升自己的编程技术。无论你是初学者还是有经验的开发者，我希望我的博客能对你的学习之路有所帮助。如果你觉得这篇文章有用，不妨点击收藏，或者留下你的评论分享你的见解和经验，也欢迎你对我博客的内容提出建议和问题。每一次的点赞、评论、分享和关注都是对我的最大支持，也是对我持续分享和创作的动力。
