これは主観的な答えです。
まず、Boostについて：Boostが構築されたら、どのような方法でも、bjamを使用する必要はありません。したがって、特定のライブラリがシステム上または特定のパスにあることを要求しながら、自分に合った任意のビルドシステムを使用できますが、それらはビルドされます。補足として、ブーストの多くはヘッダーのみです（単体テストフレームワークでもヘッダーのみのIIRCを使用できますが、ライブラリバージョンを使用することをお勧めします）。ブーストバイナリが必要だとしましょう。
プロジェクトIMOを処理する最良の方法は、自分のプロジェクトに最も適した自分で選択したビルドシステムを使用し、依存関係（ブースト）を「事前にビルド」する必要があることです。それらがどのように事前構築されるかは、各依存関係によって異なります。選択したものと同じビルドシステムを使用するものもあれば、独自のビルドシステムを使用するものもあります。一部はすべてのプラットフォーム用に作成されます。たとえば、一部はWindowsでコンパイルされますが、Windowsに適した最適なビルドシステムを備えていません。それらが小さなライブラリである場合は、ビルドシステムに統合できます。そうでない場合は、プロジェクトをビルドする前に開発者が「何らかの形で」持つ必要がある「依存関係」と考えてください。ここでの「どういうわけか」は、READMEで説明されます。
たとえば、プロジェクトにはcmakeを使用しますが、プロジェクトではBoostと他のいくつかのライブラリを使用します。cmakeを使用すると、MSVC、C :: B、GNUMakeなどのプロジェクトファイルを生成できますが、cmakeを使用してすべての依存関係を設定することはできません。非常に小さくて安定したライブラリの場合、それらのライブラリ用にcmakeプロジェクトを作成できます。そうすれば、物事は非常に簡単になります。より大規模またはより揮発性の高いライブラリの場合は、それぞれを独自のビルドシステムに任せるのが最善です。揮発性ライブラリは頻繁に変更されるため、それらの「カスタム」を構築する場合は、ライブラリの変更に合わせて「カスタマイズ」を常に調整する必要があります。使用するライブラリごとに、BOOST_LIB_INCLUDE_PATHS、BOOST_LIB_LIBRARY_PATHS、BOOST_LIB_LIBRARIESなどのcmake変数があります。これらは、開発者がプロジェクトをコンパイルすることで、それらの値に定義できます。
これらのライブラリにソースを提供するかどうかは自分で決めることができます。特にライブラリの特定のバージョンに依存したい場合は、何も問題はありません。しかし、それらを依存関係としてスクリプト化することは、揮発性ライブラリのメンテナンスに加えて、大きな混乱になる可能性があります。
ただし、Google Chromiumプロジェクトが構築されると、100のライブラリがダウンロード、チェックアウト、構築、リンクされることを私は知っています。ChromiumはビルドシステムIIRCとしてGYPを使用しています。