私は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ます）ではなく、インクルードファイルを参照する方法についてです。
ブーストを見ると、同様のスキームを使用していることに気付くでしょう。
#include <boost/shared_ptr.hpp>
これには、別の依存関係からの別の同様の名前のファイルとの衝突を防ぐという利点があります。
ただし、ブーストの場合は、さらに一歩進んでいます。を含めると、名前の付いたエンティティ（関数またはクラス）<x/y/z.hpp>を処理している可能性があります。::x::y::zつまり、プロジェクト内のディレクトリのレイアウト方法は、名前空間の編成を模倣しています。自分の向きを変えるのは本当にすてきです。
通常、ほとんどのプロジェクトはサブディレクトリ（およびサブネームスペース）に隠されていますが、最もよく使用されるプロジェクトはboost便宜上名前空間に取り込まれるため、ヘッダーがboostフォルダーに直接存在します。いくつかの便利なヘッダーもあります（その仕事は、他のヘッダーを少し集めて一度にまとめることです）。
最後に、ヘッダーファイルを開くと、それらが使用するインクルードガードがまったく同じ階層に従うことに気付くかもしれません。
#ifndef BOOST_SHARED_PTR_HPP_INCLUDED
もう一度言いますが、これは、ファイルが含まれているファイルにちなんで名付けられており、Boostプロジェクト全体（大文字と小文字を区別するファイルシステムの場合）でその場所に存在できるのは1つだけであるため、衝突を回避するのに役立ちます。
インストール時にprojディレクトリを作成する場合は、パスにprojを含めてもかまいません。実際、他のインクルードファイルとの名前の衝突を防ぐための良い方法です。
ただし、名前は「proj」のような一般的なものであってはなりません。プロジェクトに固有のものである必要があります。