WindowsとLinuxの両方のコンパイル用のAutotoolsとCMake
AutotoolsとCMakeの長所と短所を探しています。しかし、私はこれらのツールの1つ（または両方）をプロジェクトに使用した人々からの意見を知りたいです。
Autotoolsを基本的に1年前に使用しましたが、良い点の1つはシェルスクリプトに依存しているため、実行するためにインストールする必要がなく、ポータブルシェルスクリプトを使用することです。しかし、それはあまりにもunix指向であるように見え、Windowsで構成ファイルを実行することはできません。
オープンソースプロジェクト 用のビルドシステムツールを選択する必要があります。これは、少なくともLinuxおよびWindows用にコンパイルする必要があります。それはC++で書かれており、Qt GUIフロントエンドを使用し、残りは「汎用」です。
助けてくれてありがとう。
Windows用のautotoolsはお勧めしません。 CMakeを使用します。
どうして？ Windowsにはネイティブのsh.exeがなく、エミュレーションが遅いです。また、構成上の問題が非常に発生しやすくなります。 CMakeでは不可能だと言っているわけではありませんが、CMakeはより抽象化されているので、心配する必要はありません。 CMakeのドキュメントは少し読みにくいかもしれませんが、一度設定すると、CMakeでこれまでサポートされていたすべてのツールチェーンで問題ないはずです。 CMakeはテスト、パッケージングなども統合します...
AutotoolsはWindowsでは遅く、MSVCでは簡単に動作せず、Windows（およびその他のOS）で奇妙な癖があり、デバッグや修正が困難です。 libtoolはWindowsにも対応しています。Windowsは、共有ライブラリの構築を拒否することがよくあります。ツールチェーンの再配置の問題はlibtoolにも広がっており、ユーザーのツールチェーン内の誤ったファイルを調べる可能性があります。 CMakeはこの点ではるかに簡単です。ターゲットプラットフォームに関する通常のことを想定し、一般的で優れたビルド手順を作成します。
また、CMakeは出力に色を付けています:)および素敵な進捗率。
PS：私はユーザーとしてWindowsでCMakeとautotoolsを使った経験があります。 CMakeは機能する傾向があり、autotoolsは見ていないと耳を噛みがちになり、奇妙なエラーが原因で失敗すると笑顔になります...
2019年1月16日更新：ツールの進化に伴う洗練されたアドバイス。
私は以前かなり長い間autotoolsを使っていました。
現在、私は meson を集中的に使用しており、必要なときだけcmakeを使用しています。
いくつかの個人的なアドバイス：
大きなチームでは、XCodeのジェネレーターを利用する場合はCMakeを使用してください。必要なければ、直接Mesonを使用します。 Mesonは、バージョン0.49以降、CMake構成ファイルの検索もサポートしています（ただし、これがどのように機能するかはまだテストしていません）。また、現時点では、Visual Studioは十分にサポートされているようですが、私は自分で試したわけではありません。 CMakeの利点は、Visual Studioと統合されていることです。
Autotoolsをドロップします。メソンはすでにすべてをうまくカバーしています。彼らのクロスコンパイルモデルは驚くほど理解可能です。 CMakeでは、前回チェックしたとき、すべてがかなり困難でした。
フル機能を備えたクロスプラットフォームシステムはCMakeですが、pythonなど）に慣れている人はmesonのDSLを使用する方が簡単です。Mesonは、 VSもサポートします（VS2015ジェネレーター）。一部のプロジェクトでは、たとえばgstreamerなどの実験的サポートがすでにサポートされています。Gstreamerは、mesonを使用してWindowsでもコンパイルされています。 meson 0.37.1の時点でいくつかの作業が必要でしたが、それらはそれらを改善しており、現在のバージョンはすでに0.40です。
中間子
長所：
- DSLはまったく邪魔になりません。実際、これはPythonをベースにしており、非常に使い慣れています。
- よく考えられたクロスコンパイルのサポート。
- オブジェクトはすべて厳密に型指定されています。オブジェクトは「依存関係」、「ディレクトリを含める」などのエンティティであるため、文字列置換のミスを簡単に行うことはできません。
- ツールの1つにモジュールを追加する方法は非常に簡単です。
- クロスコンパイルは、より簡単に使用できます。
- 本当によく考えられています。 Mesonの設計者およびメインライターは、ビルドシステムを設計するときに彼が非常によく話していることを知っています。
- 特にインクリメンタルビルドでは、非常に高速です。
- ドキュメントは、cmakeで見つけることができるものよりも10倍優れています。 http://mesonbuild.com にアクセスすると、チュートリアル、ハウツー、および適切なリファレンスが見つかります。それは完璧ではありませんが、それは本当に発見可能です。
短所：
- ただし、CMakeほど成熟していませんが、C++ではすでに完全に使用できると思います。
- 利用可能なモジュールはそれほど多くありませんが、gnome、qt、および一般的なモジュールはすでに存在しています。
- プロジェクトジェネレーター：VSジェネレーターは今のところうまく機能していないようです。 CMakeプロジェクトジェネレーターは、はるかに成熟しています。
- Python3 +忍者の依存関係があります。
Cmake
長所：
- 多くの異なるIDEのプロジェクトを生成します。これはveryチームにとって素晴らしい機能です。
- Autotoolsとは異なり、windowsツールでうまく機能します。
- 成熟した、ほぼ事実上の標準。
- Microsoftは、Visual StudioのCMake統合に取り組んでいます。
短所：
- よく知られている標準やガイドラインには準拠していません。
- アンインストールターゲットはありません。
- DSLは奇妙です。比較などを始めたとき、文字列とリストを比較したり、エスケープ文字を使用したりすると、多くの間違いを犯します。
- クロスコンパイルは最悪です。
Autotools
長所：
- クロスコンパイルのための最も強力なシステム、IMHO。
- 生成されたスクリプトには、シェル、シェル、およびビルドする必要がある場合はコンパイラ以外は必要ありません。
- コマンドラインは本当に素敵で一貫しています。
- UNIXの世界の標準、たくさんのドキュメント。
- 本当に強力なコマンドライン：インストール、アンインストール、バイナリの名前変更のディレクトリを変更...
- Unixを対象とする場合、このツールを使用してソースをパッケージ化すると非常に便利です。
短所：
- Microsoftのツールではうまく機能しません。本当のショートッパー。
- 学習曲線は...まあ...しかし、実際にはCMakeもそれほど簡単ではなかったと言えます。
- 再帰的なmakeの使用は、レガシープロジェクトで広まっています。 Automake 非再帰的ビルドをサポートします ですが、あまり広く使用されているアプローチではありません。
学習曲線については、次の2つの情報源から学ぶことができます。
最初のソースを使用すると、起動が速くなります。本は、より深い議論です。
Scons、wafおよびtupから、Sconsおよびtupはよりmakeに似ています。 Wafは、CMakeやautotoolsに似ています。最初はcmakeの代わりにwafを試しました。完全なOOP APIを備えているという意味で、過剰に設計されていると思います。スクリプトはまったく短く見えず、作業ディレクトリや関連するものを本当に混乱させました。結局、autotoolsとCMakeの方が適していることがわかりました。
Tup
長所
- 本当に正しいです。
- めちゃくちゃ速い。信じてみてください。
- スクリプト言語は、10分で理解できる非常に簡単なアイデアに依存しています。
短所
- フル機能の設定フレームワークはありません。
docなどのターゲットを作成する方法を見つけることができませんでした。これらのファイルは私が知らないファイルを生成し、生成する前に出力にリストする必要があるためです。少なくとも、それが今のところ私の結論です。私にはよくわからないので、もしそうなら、これは本当に厄介な制限でした。
全体として、私が新しいプロジェクトについて今考えているのは、CmakeとMesonだけです。機会があればtupも試してみますが、configフレームワークが不足しているため、必要なすべてのものが必要になると、複雑になります。一方、それは本当に速いです。