C ++ビルドシステム-使用するもの
私は、C++で新しいプロジェクトを開始することを検討しています（最初は自分の時間だけです）。利用可能なビルドシステムを調査しています。答えは「多く、そして彼らはすべてひどい」と思われます。
これに特に必要な機能は次のとおりです。
- C++ 11サポート
- クロスプラットフォーム（メインターゲットとしてLinuxが、少なくともWindowsでもビルド可能）
- 適切な単体テストのサポート
- コードを分離するための複数のモジュールのサポート
- コード生成のサポート（asn1cまたはprotobufの使用-まだ100％確実ではありません）
- メンテナンスが簡単
これで、CMakeとAutotoolsを使用したユーザーのうち、1〜4個を簡単に実行できることがわかりました。おそらくSConsとWaf、そして他のカップルも。問題は、それらを使用してコード生成を正しく実行する方法を一度も試したことがないことです。つまり、ビルドプロセスが最初に実行されるまで存在しないソースファイルであるため、ビルドシステムが実行可能コードに変換できる必要があるソースファイルしかし、実際にはビルドが開始するまで知りません...（特に、ASN1Cは、連携して動作する必要があるヘッダーファイルとソースファイルを多数生成します。実際に生成されるファイルセットは、asnファイルの内容によって異なります）また、これらのどれも特に保守が容易ではないという事実-CMakeとAutotoolsには、それらが機能するために管理する必要がある独自の巨大なスクリプトセットがあり、WafとSconsは、それらを扱う誰もがpython（私はしません）それらを使用して...
だから-このようなものにはどのビルドシステムが推奨されていますか？それとも、今のところmakeファイルとシェルスクリプトにこだわるでしょうか？
+1、「多く、そして彼らはひどい」。
しかし、「最もリッチ」で「最もスケーラブル」なのはおそらく CMake で、これはMakefileジェネレーターです（ネイティブMSVC++ *.proj/*.slnも生成します）。奇妙な構文ですが、一度学習すると、さまざまなプラットフォーム用のビルドをうまく生成できます。 「新しく始めた」場合は、おそらくCMakeを使用します。リストを処理する必要がありますが、あなたの「コード生成」は、あなたが何をしたいのかによって、ビルドシステムを超えて「自分の命」を引き受けることができます。 （下記参照。）
単純なプロジェクトの場合、 QMake ジェネレーターは問題ありません（QMakeを使用するためにQtライブラリを使用する必要はありません）。しかし、あなたは「単純」を説明していません-コード生成と「余分なフェーズ」は、おそらくCMakeまたはScons（またはWaf）のような独自の拡張用の豊富なAPIを必要とすることを意味します.
職場では Scons を使用しています。 「防弾ビルド」を生成しますが、本当に遅いです。 Sconsほど安全なシステムは他にありません。しかし、それは遅いです。それはPythonで書かれており、「ワークスペース組織」（単にモジュールの依存関係を指定する）のインターフェースを拡張し、それはScons設計意図の一部です（Pythonを介したこのタイプの拡張） ）。便利ですが、ビルドは遅くなります。防弾ビルドを入手できます（どの開発者ボックスでも最終リリースを作成できます）が、時間がかかります。そして、それは遅いです。ただし、Sconsを使用する場合は遅いことを忘れないでください。そして、それは遅いです。
2000年から10年経った今でも、空飛ぶ車がないと考えるのは気分が悪くなります。おそらくそれらを取得するために、さらに100年または何かを待たなければなりません。そして、私たちはおそらく、stillが空っぽのビルドシステムで構築されている空飛ぶ車の中で飛び回っているでしょう。
はい、彼らはすべてひどいです。
[コード生成について]
Sconsは「フェーズ」で動作し、「やや静的」です。ビルドの一部として生成されるコードをビルドできます（人々はこれをいくつかの異なる方法で実行しています）が、これは「非常に非Sconsに似たもの」と説明されています。
単純な「いくつかのファイルの前処理とソースファイルの生成」であれば、大したことはありません（多くのオプションがあるため、*.hpp/*.cppファイルのqmake前処理のためにmocが記述されています）。
ただし、これを「重荷」で行う場合は、独自のスクリプトを作成する必要があります。たとえば、（従来の3層アプリケーション開発で）「レイヤー」間のインターフェイスとしてデータベースにクエリを実行し、C++クラスを生成するビルドオブアズビルドスクリプトがありました。同様に、IDLを介してサーバー/クライアントのソースコードを生成し、バージョン情報を埋め込み、複数のクライアント/サーバーを異なるバージョンで同時に実行できるようにしました（同じ「クライアント」または「サーバー」に対して）。多数の生成されたソースコード。これは「the-build-system」である「ふり」をすることもできますが、実際には「構成管理」のための重要なインフラストラクチャであり、その一部は「build-system」です。たとえば、このシステムでは、このプロセスの一部としてサーバーを「テイクダウン」および「スタートアップ」する必要がありました。同様に、回帰テストはこのプロセスの一部として実行され、バージョン間の重い「レポート」と「差分テスト」が行われました。すべてが「ビルドスクリプト」の一部です。
今すぐGradleを使用できます： https://docs.gradle.org/current/userguide/native_software.html
これは、私が最初に投稿してから数年でかなり成熟したようです。プロジェクトが「インキュベーション中」であるというページは消えましたが、このステータスを削除する公式の発表を見つけることができません。
私は最近これらについて知りました、私はまだ個人的にそれらを使用していません：
Ninja 、速度に焦点を当てた小さなビルドシステム。 Googleは、Make： link の代わりにNinjaを使用してAndroidを構築するようになりました。
Shake 、強力で高速なビルドシステム。
Tup 、高性能ビルドシステム。 アルゴリズム ベースのデザイン。 Tupの分析 。
すべてがクロスプラットフォームになり、Windowsをサポートするようになりました。残りの要件についてはまだわかりませんが、まだ自分でテストしていません。それらは商業開発で使用されており、 CIG は忍者を選びました。最初の2つはScons、Antなどに似ています。
Sconsは非常に友好的で柔軟性のあるシステムですが、そうですね、Lothar、本当に遅いです。
しかし、Pythonで書かれたプログラムのパフォーマンスを向上させる方法があります。このJITの使用。すべての既知のプロジェクトの中で、PyPyは非常に強力で、急速に成長し、意欲的なJIT支援のPython 2.7実装です。 Python 2.7とのPyPyの互換性は驚くべきものです。ただし、Sconsは PyPy互換性wiki でサポートされていないプロジェクトとして宣言されています。 Wafは、一方で、Pythonベースのautotoolsの後継としてモデル化され、PyPyインフラストラクチャによって完全にサポートされます。私のプロジェクトでは、PyPyへの移行でアセンブリの速度が5〜7倍に増加しました。 PyPyからパフォーマンスレポートを表示できます 。
モダンで比較的高速なビルドシステムには、Wafが適しています。
Googleビルドシステムは優れた代替手段です。 http://bazel.io/
私はSConsを使用し、このビルドシステムに感銘を受けました。 SConsはpythonおよびpython自体によって拡張可能です-Pythonには必要なものがすべて揃っているため、ロジックをコーディングするだけで、すべての低レベル機能がSConsおよびPythonで既に実装されており、クロスプラットフォームです。優れたプログラミングスキルがあれば、ビルドスクリプトは完璧で簡単に見えます。
Make、CMake、および同様のビルドシステムは、マクロのゴミのようです。 WafはSConsアナログです。私はWafを試していますが、SConsはよりフレンドリーになるので、SConsにとどまりました。
群衆の意見では、SConsは遅すぎますが、プロジェクトの途中では、ビルド速度によるmakeとSConsの違いは見られませんでした。代わりに、SConsは並列ビルドでうまく機能しましたが、makeには大きな問題があります。
また、SConsを使用すると、テンプレートの構成、構築、デプロイ、構成の生成、テストの実行、および実行可能な他のタスクを実行できます。これらのタスクは、pythonおよびSConsでコーディングできます。それは非常に大きな利点です。
単純なプロジェクトの場合、CMakeも良い選択です。