我理解你的困惑。让我们试着把事情弄清楚。
我猜你所说的构建选项是指在调用 CMake 时指定为命令行参数的选项（例如cmake -DFOO=Bar ..）。其作用是将 CMake 缓存中的变量设置FOO为 value Bar。然后，CMake 脚本可以像 CMake 中的任何其他（缓存）变量一样使用它。请注意，缓存的变量在 CMake 的不同运行之间保留。这意味着，除非用户在运行之间删除了 CMake 缓存，否则 CMake 将记住上次运行中的选项，而无需用户在命令行上重新声明该选项。然而，每次他们第一次运行 CMake 时，都需要重新声明该选项。
CMake 选项的工作原理完全相同，但 CMake 知道该变量应该由用户事先设置，因此更加方便。在命令行上这根本没有什么区别，但如果您的用户使用ccmake或cmake-gui前端（或了解 CMake 选项的 IDE），该选项将显示在那里。因此，对于您希望由用户设置的变量，不要只在脚本中使用它们并假装您的用户会了解它们 - 设置适当的 CMake 选项，以便该变量作为构建选项显示在前端对于用户来说。
环境变量有不同的用途——它们描述环境。与为每个构建单独声明的构建选项不同，环境变量应包含有关永不更改的系统的信息。例如，在搜索系统上的依赖项时find_package 考虑环境变量Package_ROOT（ ，其中 Package 是依赖项的名称）。这是有道理的，因为您的系统上可能只安装了该软件包，然后所有依赖它的项目都会使用该软件包。您不必在每次新的 CMake 运行时重新声明依赖项的位置，只需设置一次环境变量，它就会从那时起开始工作（直到您从其原始位置删除依赖项）。
但是等等，如果我只想使用该依赖项的不同安装来构建项目 X，该怎么办？我不想每次构建 X 时都必须更改环境变量，并且必须在之后将其更改回来......这就是为什么find_package，除了环境变量外，还考虑同名的CMake变量。这样，用户仍然可以通过构建特定选项覆盖环境变量中的系统范围设置。因此，这两种机制并不相互排斥。
仔细考虑您的用户将如何使用相应的选项并相应地选择机制。