试试这个

SET(ENV{LD_LIBRARY_PATH} "/path/to/library/dir:$ENV{LD_LIBRARY_PATH}")

我还用这个卑鄙的伎俩临时改变了一些环境变量：

LD_LIBRARY_PATH="/path/to/library/dir:$LD_LIBRARY_PATH" cmake ...

执行此行后，当前shell中的LD_LIBRARY_PATH不会发生更改。
另外，我认为在调用cmake之前更改LD_LIBRARY_PATH也不错：export LD_LIBRARY_PATH=...
它不会改变系统范围内的任何东西，但是它将用于当前的shell和当前的构建过程，这同样适用于CI构建。您可以保存该变量，并在cmake调用后恢复它：

MY_LD=$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=...
cmake...
export LD_LIBRARY_PATH=$MY_LD

我最近遇到了一个类似的问题。我的解决方案是在每个命令中加入一个设置适当环境的源文件。例如，下面的自定义命令：

add_custom_command(
    OUTPUT some_output
    COMMAND some_command
    ARGS some_args
    DEPENDS some_dependencies
    COMMENT "Running some_command some_args to produce some_output"
    )

会变成：

set(my_some_command_with_environment "source my_environment_script.sh && some_command")
add_custom_command(
    OUTPUT some_output
    COMMAND bash
    ARGS -c "${my_some_command_with_environment} some_args"
    DEPENDS some_dependencies
    COMMENT "Running some_command some_args to produce some_output"
    VERBATIM
    )

显然，这有一些缺点：

• 它依赖于可用的bash shell。
• 它为每个命令调用提供环境脚本（性能问题），您将必须更改依赖于该环境变量的所有命令调用。
• 它改变了命令跟在COMMAND后面而参数跟在ARGS后面的常规语法，因为现在'真实的'命令是ARGS的一部分。

我的CMake-Fu已经被证明不足以找到一个语法上更好的方法来做这件事，但也许有人可以评论一个更好的方法。

对于第三方库提供的可执行文件，我也遇到了类似的问题。该二进制文件链接到了发行版没有提供的库，但所需的库包含在第三方库的libs目录中。
所以运行LD_LIBRARY_PATH=/path/to/thirdparty/lib /path/to/thirdparty/bin/executable是可行的。但是包配置脚本没有设置可执行文件来搜索/path/to/thirdparty/lib的运行时依赖项，所以当CMake试图运行可执行文件时，CMake会抱怨。
我通过配置一个引导脚本并将IMPORTED_LOCATION属性替换为配置的引导脚本来解决这个问题。
在CMakeLists.txt中的_第三方执行
老实说，我认为这是一个黑客和暂时停止差距，直到我修复第三方库本身。但就我所尝试的，这似乎工作在所有的IDE的我扔在它，Eclipse，VSCode，Ninja，QtCreator，等等