我正在开发 C++ 头文件库，我们称之为PROJ。当一个库头包含另一个时，它使用：
#include <proj/foo.h>
并且编译器（gcc 和 clang）有-I path-to-proj-parent. 图书馆的用户在他们的包含搜索路径中也应该有PROJ的父级。
我使用此方案的合理性是，将此库安装到proj默认可搜索父级（/usr/include/proj或/usr/local/include/proj）的子目录后，库用户无需指定-I选项。
这个方案有缺点吗？使用<foo.h>不带proj/前缀是更传统和推荐的方式吗？
问题不在于是否安装在子目录中（会有proj子目录），而是如何引用包含文件。
如果您查看 boost，您会注意到它们使用了类似的方案：
#include <boost/shared_ptr.hpp>
它具有防止与来自另一个依赖项的另一个类似名称的文件发生冲突的优点。
然而，在提升的情况下，他们更进一步。如果您包含<x/y/z.hpp>，那么您可能正在处理一个名为的实体::x::y::z（无论是函数还是类）。也就是说，项目中目录的布局方式模仿了命名空间组织。定位自己真的很整洁。
通常，大多数项目都隐藏在子目录（和子命名空间）中，但为了方便起见，最常用的项目被拉入boost命名空间，因此它们的标题直接位于boost文件夹中。还有一些方便的标头（其工作只是收集少量其他标头以一次将它们全部拉入）。
最后你可能会注意到，如果你打开一个头文件，它们使用的包含保护遵循完全相同的层次结构：
#ifndef BOOST_SHARED_PTR_HPP_INCLUDED
再一次，因为它有助于避免冲突，因为它是以它所在的文件命名的，并且在整个 Boost 项目的那个地方只能有一个（在区分大小写的文件系统上）。
如果在安装时创建 proj 目录，则路径中有proj是可以的。事实上，它是防止与其他包含文件发生名称冲突的好方法。
不过，名称不应该是像“proj”这样的通用名称。它应该特定于项目。