Question

我正在为OpenGL构建一个非常轻量级的库/包装器，我遇到了一个小问题。假设我有一个看起来像这样的目录结构：

GraphicsProject
|GraphicsApp
||main.cpp
|GraphicsLib
||include
|||fileA.h
|||fileB.h
||library
|||fileA.cpp
|||fileB.cpp
||shaders
|||shader1.txt
|||shader2.txt
|| build
||| bunch of build stuff

在运行时获取shader1.txt路径的最佳方法是什么？或者，不管是谁在使用这个项目或者它在用户机器上的位置，都要使路径不会改变？

我考虑过的一些选项： 1）获取当前工作目录并使用该路径直到我需要的位置。我对此解决方案的主要关注是，我不确定当前目录将根据用户构建项目的方式或其他因素而无法控制。它也感觉不是很优雅。 2）将着色器的源代码存储为char数组/字符串，位于include目录中的.h文件中。这似乎是一个更好的解决方案，除了它会使着色器编写稍微麻烦。

有没有一种标准的方法可以做到这一点？我正在使用CMake构建项目，如果这改变了什么。

Answer 1

我假设您正在谈论将“着色器”文件夹提供给正在构建项目的其他开发人员，因为如果您的意思是最终用户（这将涉及install组件）您将不会不是在谈论构建文件夹。

我认为在运行时为shaders文件夹提供固定位置的最简单方法是将其从源树复制到构建树。通过这种方式，其他开发人员可以将他们的根构建文件夹放在项目之外的任何位置（如果他们想要，甚至可以放在内部），并且应用程序在访问复制的着色器文件夹时仍然只有一个固定的相对路径来处理。

如果您不想复制，其他选项（例如，您可以让CMake将配置文件写入构建树;配置文件可以指定着色器文件夹的路径）但我认为它们更复杂，可能更脆弱。无论如何，我认为关键是在配置时将信息从源树复制到构建树（当CMake执行时），这样运行时代码就不会难以搜索可能非常远的源树。

示例根CMakeLists.txt将是：

cmake_minimum_required(VERSION 2.8 FATAL_ERROR)
project(example)

add_executable(GraphicsApp GraphicsApp/main.cpp)
add_library(GraphicsLib
    GraphicsLib/library/fileA.cpp
    GraphicsLib/library/fileB.cpp
    GraphicsLib/include/fileA.h
    GraphicsLib/include/fileB.h
    GraphicsLib/shaders/shader1.txt
    GraphicsLib/shaders/shader2.txt
    )
include_directories(GraphicsLib/include)
target_link_libraries(GraphicsApp GraphicsLib)

add_custom_command(TARGET GraphicsApp POST_BUILD
    COMMAND ${CMAKE_COMMAND} -E copy_directory
        ${CMAKE_SOURCE_DIR}/GraphicsLib/shaders
        $<TARGET_FILE_DIR:GraphicsApp>/shaders)

要在add_custom_command调用上稍微扩展一点，这基本上会导致“shaders”子目录被复制到将GraphicsApp构建到的文件夹中。该命令在GraphicsApp构建的任何时间执行。如果GraphicsApp已构建并且是最新的，并且您尝试重建它，则不会执行自定义命令。

自定义命令实际执行

cmake -E copy_directory <path to shaders source> <path to shaders copy>

利用CMake的-E跨平台命令模式。

命令的“目标”部分（“复制到”位置）使用生成器表达式推导出GraphicsApp将构建到的位置：$<TARGET_FILE_DIR:GraphicsApp>。这可能是实现这一目标最有力的方式;无论配置类型如何，它都是正确的（例如，MSVC在构建路径中插入“Debug /”或“Release /”文件夹）。

因此，希望能够帮助您实现目标。我想你仍然必须get the full path to the running exe然后推导出复制的着色器文件夹的完整路径。但是，与从当前工作目录中搜索相比，这应该更加简单和健壮。即使calculating the current working dir也是非平凡的。

如何处理C ++库中的资源

1 个答案: