Question

我正在开发C ++头文件库，我们称之为 PROJ 。当库头包含另一个时，它使用：

#include <proj/foo.h>

编译器（gcc和clang）有-I path-to-proj-parent。该库的用户还应在其包含搜索路径中拥有 PROJ 的父级。

我理性地使用这个方案是在将此库安装到default-seachable parent（proj或/usr/include/proj）的/usr/local/include/proj子目录中之后，库用户不需要指定{{ 1}}选项。

这个计划有缺点吗？使用-I而没有<foo.h>前缀是更传统和推荐的方式吗？

问题不在于是否在subdir中安装（将有proj/ subdir），而是如何引用包含文件。

Answer 1

如果你看一下提升，你会注意到他们使用类似的方案：

#include <boost/shared_ptr.hpp>

它的优点是可以防止与另一个依赖项中另一个类似命名的文件发生冲突。

然而，在提升的情况下，他们更进一步。如果包含<x/y/z.hpp>，那么您可能正在处理名为::x::y::z的实体（无论是函数还是类）。也就是说，项目中的目录布局模仿命名空间组织。定位自己真的很整洁。

通常，大多数项目都隐藏在子目录（和子名称空间）中，但为了方便起见，最常用的项目被拉入boost名称空间，因此它们的标题直接存在于boost文件夹中。还有一些便利标题（其工作只是收集一些其他标题以便同时将它们全部拉出来）。

如果你打开一个头文件，你可能会注意到他们使用的包含警卫跟随the exact same hierarchy：

#ifndef BOOST_SHARED_PTR_HPP_INCLUDED

再次因为它有助于避免冲突，因为它以它所在的文件命名，并且整个Boost项目中只有一个（在区分大小写的文件系统上）。

Answer 2

如果在安装时创建proj目录，则可以在路径中使用 proj 。实际上，它是防止与其他包含文件发生名称冲突的好方法。

名称不应该像“proj”那样通用。它应该特定于项目。