C ++ビルドシステム-何を使用するか [閉まっている]


136

私はC ++で新しいプロジェクトを開始することを検討しています-最初は自分の時間内に-利用可能なビルドシステムを調査しています。答えは「たくさんあり、みんなひどい」と思われるでしょう。

これに特に必要な機能は次のとおりです。

  1. C ++ 11サポート
  2. クロスプラットフォーム(メインターゲットとしてのLinuxですが、少なくともWindows上でもビルドできます)
  3. まともな単体テストのサポート
  4. コードを分離するための複数のモジュールのサポート
  5. コード生成のサポート(asn1cまたはprotobufの使用-まだ100%不明)
  6. メンテナンスが簡単

今では、CMakeとAutotoolsを使用して1〜4人で簡単にできることがわかっています。おそらく、SConsとWafと他のカップルもそうでしょう。問題は、それらを使用してコード生成を正しく行う方法を考えたことがないことです。つまり、ビルドプロセスが最初に実行されるまで存在しないソースファイルであるため、ビルドシステムが実行可能コードに変換できる必要があるソースファイルです。しかし、ビルドが開始するまでは実際にはわかりません...(特に、ASN1Cは、連携して動作する必要がある数十のヘッダーファイルとソースファイルを生成します。実際のファイルセットは、asnファイルの内容によって異なります)。また、これらのどれも特にメンテナンスが簡単ではないという事実-CMakeとAutotoolsには、動作するように管理する必要のある独自の巨大なスクリプトセットがあります。

それで、このようなものにはどのビルドシステムが推奨されますか?それとも私は今のところメイクファイルとシェルスクリプトで立ち往生していますか?


11
「答えは「たくさんあり、すべてがひどい」のように見える」も私の印象です(「私の観点からはひどい」が追加されています。このような用語であまり一般化したくない)。その理由で実際に自分でセットアップしましたが、私が望むことを行い、常に物事を機能させたいと思っていたため、予想よりもうまく機能しました。少し時間がかかる場合は、おそらく既存のツールを調べて、他よりも頭痛の少ないツールを選択する必要があります。
クリスチャン・スティーバー

4
tupを試してください。
Kerrek SB、2012

次も参照してください:stackoverflow.com/q/3349956
ergosys 2012

8
ビルドシステムにどのようなC ++ 11サポートを期待していますか?これはコンパイラーから取得したものであり、ビルドシステムは実際のソースファイルを解析したり読み取ったりすることはなく、必要な人に渡すだけです。
バルク

5
正しいですが、C ++ 11サポートを使用するようコンパイラーに指示することを容易にすることは良いことです。g ++は1つのフラグを必要とし、clangは別のセットを必要とし、msvcは明らかに何も必要としません。また、どのc ++ 11機能が利用可能かを検出するためのサポートは、コンパイラによっても異なるので有用です...
Graham

回答:


117

「多くの場合、彼らはひどい」と+1します。

しかし、「最もリッチ」で「最もスケーラブル」なのは、おそらくMakefileジェネレーターであるCMakeです(ネイティブMSVC ++ *.proj/ も生成します*.sln)。奇妙な構文ですが、一度理解すると、さまざまなプラットフォーム用のビルドをうまく生成できます。「started-fresh」の場合、おそらくを使用しますCMake。それはあなたのリストを処理するはずですが、あなたの「コード生成」は、あなたが何をしたいかに応じて、ビルドシステムを超えて「自分の人生」を引き受けることができます。(下記参照。)

単純なプロジェクトの場合、QMakeジェネレーターは問題ありません(QMakeを使用するためにQtライブラリーを使用する必要はありません)。ただし、「単純」については説明していません。コード生成と「追加フェーズ」はCMakeScons(またはWaf)の。

私たちは職場Sconsを使用しています。「防弾ビルド」を生成しますが、それは本当に遅いです。他のシステムはほど防弾にはなりませんScons。しかし、それは遅いです。これはPythonで記述され、「ワークスペース組織」のインターフェースを拡張し(モジュールの依存関係を指定するだけです)、それはScons設計意図(Pythonによるこのタイプの拡張)の一部です。便利ですが、ビルドは遅いです。防弾ビルド(任意の開発ボックスで最終リリースを作成できます)を取得しますが、処理速度は遅くなります。そして、それは遅いです。使うなら忘れないでSconsただし、を、速度が遅いことを。そして、それは遅いです。

2000年から10年経っても、まだ空飛ぶ車はないと私は考えています。私たちはおそらく、それらを手に入れるためにさらに100年か何かを待つ必要があるでしょう。そして、私たちはおそらくまだまだ空飛ぶ車で飛び回っています安っぽいビルドシステムで構築され。

はい、彼らはすべてひどいです。

[コード生成について]

Scons「フェーズ」で機能し、「やや静的」です。ビルドの一部として生成されるコードをビルドできます(人々はこれをいくつかの異なる方法で実行しています)が、これは「Sconsに非常に似ていないもの」として説明されています。

それが単純な「いくつかのファイルを前処理してソースファイルを生成する」なら、大したことはありません(あなたには多くのオプションがあり、これqmakeが書かれた理由です- moc前処理のために*.hpp/*.cppファイルです)。

ただし、これを「ヘビーマナー」で行う場合は、独自のスクリプトを作成する必要があります。たとえば、データベースを照会し、「従来の3層アプリケーション開発では」「レイヤー」間のインターフェースとしてC ++クラスを生成する、ビルドの一部としてのスクリプトがありました。同様に、IDLを介してサーバー/クライアントのソースコードと埋め込みバージョン情報を生成し、複数のクライアント/サーバーが異なるバージョン(同じ「クライアント」または「サーバー」)で同時に実行できるようにしました。多くの生成されたソースコード。これは「ビルドシステム」を「装う」こともできますが、実際には「構成管理」の重要なインフラストラクチャであり、その一部が「ビルドシステム」です。たとえば、このシステムは「削除」と「


37
私はスコンスも好きですが、遅いと思います。
Lothar

1
コード生成時にオプションの第2フェーズを実行するMakefileラッパーを使用して、CMakeにコード生成を処理させることができます。完全な依存関係の追跡、再生成をトリガーするコード生成後の早期終了などをサポートできました。参照:javaglue.com/javaglue.html#tag : JavaGlueおよびcode.google.com/p/javaglue
sdw

3
2年近く経った今でも、SConsは遅いと思いますか?私はビルドシステムを選んでいたとき、私が出会ったこの、それはSConsは一緒に行くために私の決定に貢献しました。
JBentley 2014年

2
@ベン、それは本当ですが、それも遅いです。
チャーリー

2
これを見ている人は誰でもMeson(忍者を使用)を検討する必要があります。
マシューD.ショールフィールド2017

33

今すぐGradleを使用できます:https : //docs.gradle.org/current/userguide/native_software.html

私が最初にこれを投稿してから、これはここ数年でかなり成熟したようです。プロジェクトが「準備中」であるというページは消えましたが、このステータスを削除する公式発表はありません。


Gradleに同意します。Gradleはスケーラブルに設計されています。ただし、プラグインの実装の速度によって異なります。gradle自体のオーバーヘッドもいくつかあります。また、一部のプラグインはユースケースに合わせてカスタマイズする必要がある場合があることに注意してください。
JE42、2014

GradleがC ++のサポートに関心を持っているのを見て興味深い。彼らが私たち全員が欠けているc ++プロジェクトのための素晴らしくてしっかりした構築システムを生み出すことを望んでいます
hbobenicio 2014年

@squidありがとう、更新されました。
Nate Glenn

1
Gradleは強力でありながらシンプルです。奇妙な構文はありません。1つのgradle.buildファイルで、複数の実行可能な出力(メイン、テストなど)を含むプロジェクト全体をビルドするのに十分な場合がよくあります。すべてのソースディレクトリにまたがるファイルダンプはありません。バージョン管理にとてもフレンドリーです。
Overdrivr

1
私は過去2日間、Gradleとの戦いに「hello world」ライブラリ、アプリ、およびgtestsを作成しようとしていましたが、新しいプロジェクトに推奨できるとは言えません。ツールはすべてあるかもしれませんが、ドキュメントはありません(疑いの恩恵を与えます)。多分それが実行可能であると思うあなたの人はあなたのお気に入りのリソースを指すことができますか?
jwm

16

私はこれらを見つけました、私はそれらのすべてをまだ個人的に使用していません:

忍者、スピードを重視した小さなビルドシステム。GoogleはAndroidの作成にMake:linkではなくNinjaを使用するようになりました。

Shakeは、強力で高速なビルドシステムです。

Tup、高性能ビルドシステム。アルゴリズムに基づく設計。 タップの分析

現在、すべてがクロスプラットフォームであり、Windowsをサポートしています。他の要件についてはまだわかりません。繰り返しますが、自分でテストする必要があるためです。それらは商業開発で使用されており、CIGは忍者を取り上げました。私は忍者の使いやすさとスピードをプロジェクトジェネレーターで使用してきました。最初の2つはScons、Antなどに似ています。


1
Tupはシンボルルックアップをめちゃくちゃにして、他のビルドシステムとはうまく機能しません(実際にはまったく)、ランダムな出力(ファイルにjavac分割されている内部クラスで生成されたクラスなど)とはうまく機能しません。class$1.class不十分に書かれており、システムハックを使用してそれを実行します。小規模なシステムに最適です。大規模なプロジェクトでは維持できません。
Qix-モニカは2015年

@Qix:出力をリポジトリから分離しておくことはできませんか?
Kerrek SB、2015

1
@KerrekSBできますが、それはシンボル検索の問題ではありません。TupはFUSEを使用し、独自のミドルウェアをにマウントし.tup/mntます。次に、フォルダー(つまり.tup/mnt/@tupjob-XXXXX)内のすべてのビルドプログラムを作業ディレクトリとして実行して、読み取り/書き込みを監視し、ビルド構成を適用します。パスが絶対的に(つまり、シンボルと共に)保存されていない限り、うまく機能します。バイナリをコンパイルすると、シンボルパスはバイナリ自体に格納されます。つまり、GDBがシンボルをロードしようとするとtupjob、存在しないパスを探してエラーを引き起こします。
Qix-モニカは2015年

TupとNinjaはどちらも非常に低レベルのツールであり、Makeよりも低いか、これまでよりも低くなっています。C ++に合わせて調整されていません。これらのツールは、実際のビルドシステムが複雑な現実世界のプロジェクトを処理するために提供する重要な上位レベルの機能が不足しているため、これらのツール単独でビルドシステムと呼ぶことはありません。これらのシステムの一部は、忍者をバックエンドとして使用する場合があります。
JohanBoulé18年

11

Sconsは非常に友好的で柔軟なシステムですが、あなたの言う通り、Lotharは本当に遅いです。

しかし、Pythonで書かれたプログラムのパフォーマンスを向上させる方法があります。このJITの使用。すべての既知のプロジェクトの中で、PyPyは非常に強力で、急速に成長し、やる気のあるJIT支援のPython 2.7実装です。Python 2.7とのPyPyの互換性は単純に驚くべきものです。ただし、SconsはPyPy互換性Wikiでサポートされていないプロジェクトとして宣言されています。 一方、Pythonベースのautotoolsの後継としてモデル化されたWafは、PyPyインフラストラクチャによって完全にサポートされています。私のプロジェクトでは、PyPyへの移行中にアセンブリの速度が5〜7倍に増加しました。PyPyからパフォーマンスレポートを確認できます

モダンで比較的高速なビルドシステムには、Wafが適しています。


リンクされたWikiページでsconsが「互換」としてマークされていることは注目に値します。そのため、PyPyで動作するようです。
架空の名前

8

Googleビルドシステムは良い代替手段です:http : //bazel.io/


3
「クロスプラットフォーム(メインターゲットとしてのLinuxですが、少なくともWindows上でもビルドできます)」。BazelのFAQには、「現在、Windowsサポートの改善に積極的に取り組んでいますが、それでもまだ使用可能ではありません。」
Michael Mrozek

3
システム自体なのか、プロジェクトを立ち上げたのかはわかりませんが、仕事で使うのが大変でした。それは非常に柔軟性がなく(物事を行う1つの方法のみをサポートするという意味で、不気味でなくても次善の策です)、十分に強力ではなく、十分に文書化されていません(基本的なケースを除いて)、コミュニティーはほとんどないため、stackoverflowがあなたを救ってくれると期待しないでください、それ自体はかなり依存しているため、ほとんどのシステムなどのほとんどのIDEではうまく機能しません。したがって、Googleのファンでない限り、近づかないでください(Buckと呼ばれるFacebookのバージョンがあります)。 Facebookファン向け)
スラバ

ねえ、私はCMakeを動作させるために6週間を費やした後、本当に使いやすいことがわかりました。サードパーティの依存関係をダウンロードしてコンパイルすることを望んでいました(PythonとJavaScriptからの素晴らしいビルドツールに慣れていたため)。これにより簡単になりましたが、サポートしていないサードパーティ用に独自のbazelファイルを作成する必要があるかもしれないという欠点があります。これらをi'ze reckonに保存するには、中央レポが必要です。
CpILL

6

私はSConsを使用し、このビルドシステムに感銘を受けました。SConsはpythonとpython自体で拡張可能です。Pythonには必要なものがすべてあり、ロジックをコーディングするだけなのですばらしいです。低レベルの機能はすべてSConsとPythonにすでに実装されており、クロスプラットフォームです。優れたプログラミングスキルがあれば、ビルドスクリプトは完璧で簡単に見えます。

Make、CMake、および同様のビルドシステムは、マクロのゴミのようです。WafはSConsアナログです。私はWafを試していますが、SConsの方がフレンドリーなので、SConsを使い続けました。

群衆の意見では、SConsは遅すぎますが、プロジェクトの途中で、ビルド速度によるmakeとSConsの違いはわかりませんでした。代わりに、SConsは並列ビルドでうまく機能しましたが、makeには大きな問題があります。

また、SConsを使用すると、構成、構築、展開、テンプレートからの構成の生成、テストの実行、およびPythonとSConsを使用したコーディングが可能なその他のタスクをすべて1つにまとめて実行できます。それは非常に大きな利点です。

単純なプロジェクトの場合、CMakeも適切な選択です。


3
ここでの私の問題は、私が甘やかされていることです。私は職業別のJava開発者であり、Javaの世界でGradleのようなツールは、C ++開発で本当に使用したい種類のツールです。単一行のビルドファイルを使用して、外部依存関係なしでGradleプロジェクトを設定できます。それでおしまい。多数の依存関係を持つマルチモジュールプロジェクトも同様に簡単に実行でき、実際には単純なC ++プロジェクトよりも構成がはるかに少なくて済みます
Graham

-I include dirsおよび-L library dirsのようなシステム構成フラグを抽象化しないため、Sconsを使用する他のパッケージの構築に問題がありました。CFLAGSは必要ありません。適切な場所に表示されるようにするには、各sconsスクリプトを変更する必要があります。
2016

5

ちょうど私のセントを追加する:premake

http://industriousone.com/premake

Wikiには専用のWebページもあります。


2
残念ながら、PremakeはOPの要件によるコード生成をサポートしていません。そして、できることはいくつかありますが、単体テストのサポートを「まとも」とは言いません。
ergosys 2012

@ergosys私はantが言及されていないことに気づき、antC / C ++もサポートしています。これがあなたに良いかどうかを確認してください。これは私が持っている最後の名前です。これにはMakefilesとCmakeを使用します。
user827992

2

Ceedlingを使用できます。ただし、現時点ではCのみをサポートしており、作成者のUnityおよびCMockテストフレームワークと密接に結合しています。

C ++コンパイラと単体テスト/モックフレームワークでかなり簡単に動作するようにフォークおよび変更できます。

また、Tupをは立派な言及があります。非常に高速ですが、フレームワークのテストなどについて何も知りません。つまり、Tupを使用して独自のビルドシステムを作成する必要があります。TDDを計画している場合は、おそらくTupが適しています。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.