有没有像include目录别名这样的概念

Is there a concept like include directory aliases?

本文关键字：别名 include 有没有      更新时间：2023-10-16

在一个跨平台项目中，我使用了许多第三方库。我最终决定将它们的源代码包含到我的存储库中，而不需要在每个平台上再次下载它们。这是许可证允许的。

要包含这些库的头，我需要指定它们的文件路径。有些库在name/include/name/file.h中有它们，但通常情况下，每个库都有不同的目录结构。

我希望在代码中始终以#include "name/file.h"的形式包含头，其中name是库的名称。但我既不想修改库的目录结构，也不想将所有标头复制到所需结构的include目录中。

有没有一种方法可以定义像include目录别名这样的东西？例如，Bullet Physics的标头在bullet/src中，Sqlite直接在sqlite中，SFML在sfml/include/SFML中。我想具体说明一下：

#alias "dependencies/bullet/src" "bullet"
#alias "dependencies/sqlite" "sqlite"
#alias "dependencies/sfml/include/SFML" "sfml"

使得#include "sfml/System.hpp"等价于
#include "dependencies/sfml/include/SFML/System.hpp"。

该技术不必处于预处理器阶段。例如，它也可以是一个CMake标志，以正确的方式生成项目。然而，我认为编译器必须以某种方式意识到这一技术，才能使其成为可能。

否；最接近的方法是命令行上的CCD_ 8选项的集合。

此外，如果使用SFML，则建议使用#include "SFML/System.hpp"表示法；这就是你应该在代码中写的内容。然后修复编译环境，使-Idependencies/sfml/include包含在编译中，或者使用符号链接(如果它们足够可移植的话)在包含项目头的主目录中创建像SFML这样的子目录。

当安装了像SFML这样的软件包时，头文件将被放在一个目录中——默认情况下通常是/usr/local/include，通常在它下面的子目录中。也就是说，将存在目录/usr/local/include/SFML，该目录将包含SFML报头。其他软件包也是如此。您应该将这些头安装在构建区域下的某个位置，以便可以正常地找到这些头——您只需指定在其下找到这些头的基本include目录。(注意：当您安装Bullet Physics库时，标头被放置在目录.../include/bullet中，目录下有各种子目录，因此它也遵循此约定。)

否则就意味着要对抗体制，当你对抗体制时，你最终会失败。这比随波逐流更难。

我在一次构建运行中构建了所有内容(不在包中)我设法使用Cmake做了以下事情：

在最高的CMakeLists.txt 中

set(TEMP_INCLUDE_DIR ${CMAKE_BINARY_DIR}/tempIncludes)
file(MAKE_DIRECTORY ${TEMP_INCLUDE_DIR})
target_include_directories(<TARGET_NAME> PUBLIC
$<BUILD_INTERFACE:${TEMP_INCLUDE_DIR}>
)

这将在二进制目录中创建一个文件夹(当你清理你的项目时，它会被删除，这样它就不会修改你的实际文件夹结构，我假设你没有在源代码构建中使用)

然后在目标库的CMakeLists.txt中：

set(LIB_NAME <ThirdPartyLibraryName>)
set(INCLUDE_FOLDER <WhatEverThirdPartyIncludeDirectory>)
set(HEADER_FILES
${INCLUDE_FOLDER}/<Header1>.h
${INCLUDE_FOLDER}/<Header2>.h
)
file(COPY ${HEADER_FILES} DESTINATION ${TEMP_INCLUDE_DIR}/${LIB_NAME}/)

这将创建一个文件夹结构，将所有包含文件复制到标准目录中，从而允许您使用所需的#include "name/file.h"表单。

简短的回答是"否"。

有几个不同的选项：

  • Symlinks-设置自己的"myincludes"目录，然后将所有相关文件链接到它们的相对位置
  • 在你的项目中使用更复杂的-I选项
  • 编写自己的预预处理器(在给定一些规则的情况下，将给定的#include转换为"实际位置的实际文件")
  • 调整相应项目的安装目录
  • 不要执行以上任何操作，使用实际文件系统中显示的名称

我个人更喜欢"不要这样做"选项。首先，移动/更改文件的包含方式很可能会让一些人感到困惑，而且第三方代码肯定不会以这种方式编写，因此您将无法使用其他人的代码来维护这种风格。

相关文章：