Maven は、 Convention over Configurationの形式を採用していると言われています。
間違った比較をしたくはありませんが、私が理解している限り、cmakeは Java プロジェクトで maven ができるように、C++ プロジェクトで同様の役割を果たします。
それで、cmakeには構成に関するいくつかの規則がありますか、それとも各プロジェクトは一意に構成されていますか? (書き込みファイルレイアウト、テストレイアウト、ビルド出力など)
Maven は、 Convention over Configurationの形式を採用していると言われています。
間違った比較をしたくはありませんが、私が理解している限り、cmakeは Java プロジェクトで maven ができるように、C++ プロジェクトで同様の役割を果たします。
それで、cmakeには構成に関するいくつかの規則がありますか、それとも各プロジェクトは一意に構成されていますか? (書き込みファイルレイアウト、テストレイアウト、ビルド出力など)
私たちが強く推奨する1つの規則は、「ソース外」ビルドを実行することです。この場合、ビルドディレクトリにはすべてのビルド製品が含まれ、ソースツリーから完全に分離されます。通常、ソースとビルドは兄弟です。
projects
proj1-build-x86
proj1-build-x64
proj1-src
この戦略を常に推奨する2つの主な理由は、(1)ビルド製品のソースツリーをクリーンに保つことです。これにより、バージョン管理システムからの最後の更新以降に何が変更されたかを簡単に判断できます。任意のソースツリーのツリーを構築し、一方が他方に干渉することによるビルド製品や設定について心配する必要はありません。
私が取り組んでいるプロジェクトが、ソースツリーに誤っていくつかのPythonファイルを生成してしまったことに最近気づきました。しかし、x86ビルドとx64ビルドの両方を異なるビルドツリーで同時にビルドしようとしたときに気づいただけです...そして突然、生成されたpythonファイルにいくつかの行が複製されて混ざり合っていました。ビルドツリーに生成するように変更しましたが、すべて順調でした。
ただし、これはすべてCMakeのグッドプラクティスの一部であり、これらのプロジェクトを実行する賢い人々の常識と規律以外のものによって強く強制されることはありません...
Maven 3 の優雅さを体験した後、構成 C の Maven スタイル システムよりも規約を探しました。...
スケルトンを作成した後、CMAKE もチェックしました。いくつかの点が際立っていました。
CMAKE は宣言型である場合もあれば、手続き型である場合もあり、常に醜い組み合わせになってしまいます。別名、括弧なしの C の ANT です。
CMAKE 自体は移植性がありますが、プロジェクトではプラットフォームの詳細を処理する必要があり、事前に知っておく必要があります。CMAKE モジュールはおそらくこれを支援するために存在しますが、残念ながらそれらの再利用性は、Ansible ロールの約束のように見えます... 理論的には可能ですが、実際には、必要なすべての複雑さを整理するためのまともな方法になります。
つまり、CMAKE は Maven のような形や形式ではありません。これは、「クロスプラットフォーム」DSL を使用してプラットフォーム固有の makefile を生成できる、低レベルの ANT に似ています。