C++ 包括来自不同应用程序/目录的 .h 文件

including .h file from a different application/directory

提问by randomThought

I have some .h files as follows (on Linux)

我有一些 .h 文件如下（在 Linux 上）

Source/Server/connect.h
Source/Server/message.h
...

I am developing another application that needs the two .h files but is in a different directory

我正在开发另一个需要两个 .h 文件但位于不同目录中的应用程序

Source/App2/..

How can I include the connect.h file in the App2 application, considering that I use perforce and everyone else working on the application would have their own copy so adding an absolute path to the include library might not be a good idea but im not sure.

我如何在 App2 应用程序中包含 connect.h 文件，考虑到我使用 perforce 并且在该应用程序上工作的其他所有人都有自己的副本，因此向包含库添加绝对路径可能不是一个好主意，但我不确定.

EDIT: I use a proprietary build mechanism for building the code so will not be able to specify gcc options directly.

编辑：我使用专有的构建机制来构建代码，因此无法直接指定 gcc 选项。

回答by James McNellis

You can #includea relative path to the files:

您可以#include使用文件的相对路径：

#include "../Server/connect.h"

or you can add a flag to tell the compiler to look in the other directory. For gcc you can use -I../Server; for Visual C++ you can use /I"../Server"; other compilers, I'm sure, have their own flags for this purpose.

或者您可以添加一个标志来告诉编译器在其他目录中查找。对于 gcc，您可以使用-I../Server; 对于 Visual C++，您可以使用/I"../Server"；其他编译器，我敢肯定，为此目的有自己的标志。

I think the second is better in most cases, since it allows you to move your projects around while only requiring you to modify the include path in one place (the makefiles or property sheets).

我认为在大多数情况下第二种更好，因为它允许您移动项目，而只需要您在一个地方（makefile 或属性表）修改包含路径。

回答by Drakosha

What about adding include search path to he compiler, for gcc it's -I switch.

向编译器添加包含搜索路径怎么样，对于 gcc，它是 -I 开关。

回答by Thomas Matthews

I suggest removing paths from the #includestatements. As others have stated, put the paths into the parameters to the compiler. Resolve the path differences in the makefileor use environment variables (may need to do both).

我建议从#include语句中删除路径。正如其他人所说，将路径放入编译器的参数中。解决路径差异makefile或使用环境变量（可能需要两者都做）。

My experience is that files will move. Anything that doesn't use relative paths will break the build (which is very bad).

我的经验是文件会移动。任何不使用相对路径的东西都会破坏构建（这是非常糟糕的）。

回答by plinth

in addition static relative paths, you can also play with preprocessor chicanery. One technique I saw used at Adobe for cross-platform code, was to do something like this:

除了静态相对路径，您还可以使用预处理器技巧。我看到 Adob​​e 用于跨平台代码的一种技术是执行以下操作：

/* globalplatform.h */
#ifdef MAC
#define PLATFORM "../Platform/Mac/MacPlatform.h"
/* custom standard IO etc */
#define STDIO "../Platform/Mac/io/stdio.h"
#define CTYPE "../Platform/Mac/io/ctype.h"
#endif
#ifdef WIN32
#define PLATFORM "../Platform/Win/WinPlatform.h"
#define STDIO <stdio.h>
#define CTYPE <ctype.h>
#endif
/* etc */
#ifndef PLATFORM
#error undefined PLATFORM
#endif

/* some C file */
#include "globalplatform.h"
#include PLATFORM
#include STDIO
/* don't need CTYPE, no penalty */

While the platform problem isn't your problem, you can define the relative paths based on build configuration if you want to and the config changes happen in one place instead of many and client files only pull in what they need. The down side is that any tools you use for browsing header files (right-click and so on) are hosed.

虽然平台问题不是您的问题，但您可以根据需要定义基于构建配置的相对路径，并且配置更改发生在一个地方而不是多个地方，并且客户端文件只提取他们需要的内容。不利的一面是，您用于浏览头文件（右键单击等）的任何工具都被冲洗掉了。

回答by Liz Albin

You can change the compiler directives as above, or modify the path within your code (either relative or absolute).

您可以像上面一样更改编译器指令，或修改代码中的路径（相对或绝对）。

I would suggest that you consider the best locations for headers and object files (and libraries) for all your projects and set that up.

我建议您考虑所有项目的头文件和目标文件（和库）的最佳位置并进行设置。

If you have standard include and lib locations you'll simplify the development down the road

如果您有标准的包含和库位置，您将简化开发过程