どちらを選ぶべきですか：サブリポジトリ/サブモジュール、またはCMake ExternalProject？
ビルドシステムにCMakeを使用し、ソース管理（例：MercurialまたはGit）を使用するフリーソフトウェアプロジェクトFooを開発または保守しています。リポジトリはオンラインで利用できます。
さて、このプロジェクトは別のプロジェクトに依存しています。たとえば、この他のプロジェクトが提供するインクルードファイルを使用しています。 Barは独立して存在し、FOSSでもあり、パブリックソース管理リポジトリから入手できます。
現在、CMakeには、このようなサブプロジェクトをダウンロード、構成、およびビルドするためのメカニズムがあります： ExternalProject 。ただし、BarをFooソースリポジトリのサブリポジトリにすることもできます。これにより、BarはFooと一緒にチェックアウトされ、CMakeはチェックアウトされたファイルとフォルダーの構成を1つのファイル階層のように扱うことができます。
一般的に、他の方法よりも1つの方法をお勧めしますか？そうでない場合、1つのオプションを選択する際の考慮事項は何ですか？
他のプロジェクトのベンダリングは、適切な依存関係管理ツールがない場合、適切な一時的措置になる可能性があります。特に、他のプロジェクトが安定したバージョン管理されたライブラリでない場合は、SCMレベルでの操作が適切です。ベンダーまたはモノレポスタイルのプロジェクトは非常に有益です
- 一緒に開発された内部依存関係を管理するため
- 外部プロジェクトが適切なパッケージを提供しない場合、
- 外部プロジェクトの変更が速すぎて、スナップショットを効果的に維持する必要がある場合
- または、外部プロジェクトで他の変更が必要な場合。
他のほとんどの場合、利用可能な依存関係管理ツールを使用する方がはるかに簡単です。ビルドが外部システムに依存するようになったことと、依存関係管理ツールが特に優れていない場合があるため、解決策よりも多くの問題が発生する可能性があるという若干の注意点があります。しかし、具体的にはCMakeは（その多数の欠陥にもかかわらず）完全な非互換性を回避するのに非常に優れています。移植性に問題がない場合は、OTOHで単純なシェルまたは依存関係をダウンロードしてコンパイルする単純なシェルまたはPythonスクリプトをいつでも作成できます。
サブリポジトリには問題があることも指摘したいと思います。例えば。 git submoduleは、メインプロジェクトのチェックアウト中に追加の手順を必要とし、混乱するセマンティクスを持つ可能性があります。