启动目录为何会影响OpenGL可执行文件的着色器加载？

问题场景 #

你开发OpenGL项目时，通过readFile函数读取.vert/.frag格式的GLSL着色器文件，使用CMake搭配Ninja构建。遇到以下不一致的运行行为：

• 在build目录下执行./app/NAME_OF_APP.exe时，着色器未生效，画面黑屏
• 直接双击build/app/目录下的可执行文件，或进入build/app/目录后执行./NAME_OF_APP.exe，程序运行正常

核心原因 #

程序的当前工作目录（启动目录）直接决定了相对路径的解析结果。

当你从build目录执行程序时，程序的当前工作目录是build/。如果你的着色器路径是相对路径（比如shaders/vertex.vert），程序会尝试在build/shaders/下查找文件——但实际着色器文件可能位于build/app/shaders/或项目根目录的shaders/中，导致文件找不到。readFile函数会返回空字符串，后续着色器编译/链接失败，最终画面黑屏（你可能没注意到控制台输出的文件不存在错误）。

而双击可执行文件或进入build/app/目录执行时，程序的当前工作目录是build/app/，此时相对路径能正确指向着色器文件所在位置，因此加载成功。

解决方案 #

1. 配置CMake指定工作目录 #

在项目的CMakeLists.txt中，为目标程序设置调试/运行时的工作目录，确保程序启动时自动切换到正确路径：

set_target_properties(NAME_OF_APP PROPERTIES
    VS_DEBUGGER_WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/app"
)

对于Ninja构建，也可以编写简单的启动脚本，先切换到build/app/目录再执行程序。

2. 使用绝对路径加载着色器 #

通过代码获取可执行文件的所在目录，再拼接着色器的相对路径，确保无论当前工作目录是什么，都能定位到文件：

#include <filesystem>
namespace fs = std::filesystem;

std::string getShaderFilePath(const std::string& shaderName) {
    // 获取可执行文件的绝对路径并提取目录
    fs::path exePath = fs::canonical(fs::path(argv[0])).parent_path();
    // 拼接着色器文件路径（假设着色器在可执行目录的shaders子目录下）
    return (exePath / "shaders" / shaderName).string();
}

调用时使用readFile(getShaderFilePath("vertex.vert").c_str())即可。

3. 将着色器嵌入可执行文件 #

通过CMake的file(READ)命令将着色器内容编译为字符串常量，或者使用工具将着色器文件转换为头文件，彻底避免外部文件的路径依赖：

# 在CMakeLists.txt中嵌入着色器内容
file(READ "${CMAKE_SOURCE_DIR}/shaders/vertex.vert" VERTEX_SHADER_SRC)
file(READ "${CMAKE_SOURCE_DIR}/shaders/fragment.frag" FRAGMENT_SHADER_SRC)

add_definitions(-DVERTEX_SHADER="${VERTEX_SHADER_SRC}")
add_definitions(-DFRAGMENT_SHADER="${FRAGMENT_SHADER_SRC}")

之后在代码中直接使用VERTEX_SHADER宏即可获取着色器内容。

内容的提问来源于stack exchange，提问作者Jon Forhan