☰

automake と autoconf はコードをコンパイルする標準的な方法ですか?

tag-icon • tag-icon compiling programming
automake と autoconf はコードをコンパイルする標準的な方法ですか?

私は時々ソースからアプリをコンパイルし、次のいずれかを使用しています:

./configure
make
sudo make install

./autogen.shしかし最近、 configure スクリプトと make スクリプトを生成して実行するツールを見つけました。

C/C++/C#(mono) のコンパイルを効率化する他の方法はありますか? Make は少し古いようです。新しいツールはありますか? 選択肢がある場合、どれを使用すればよいですか?

答え1

Autoconf と Automake は、Unix の進化の問題を解決するために開発されました。

Unix がさまざまな方向に進化するにつれて、移植可能なコードを求める開発者は次のようなコードを書く傾向がありました。

#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif

Unix がさまざまな実装 (BSD、SystemV、多くのベンダー フォーク、その後 Linux やその他の Unix 系システム) に分岐するにつれて、移植可能なコードを書きたい開発者にとって、特定のオペレーティング システム ブランドではなくオペレーティング システムによって公開される機能に依存するコードを書くことが重要になりました。これは、Unix バージョンで新しい機能 (たとえば "send" システム コール) が導入され、その後他のオペレーティング システムで採用されるため重要です。ブランドとバージョンをチェックするコードのスパゲッティではなく、開発者は機能ごとに調査するようになり、コードは次のようになりました。

#if HAVE_SEND
Use Send here
#else
Use something else
#endif

90 年代にソース コードをコンパイルするためのほとんどの README ファイルでは、開発者に config.h ファイルを編集してシステムで使用可能な適切な機能をコメント アウトするように指示するか、テスト済みの各オペレーティング システム構成の標準の config.h ファイルを出荷するように指示していました。

このプロセスは面倒でエラーが発生しやすいため、Autoconf が生まれました。Autoconf は、特別なマクロを持つシェル コマンドで構成された言語と考えてください。これにより、config.h の人間による編集プロセスが、オペレーティング システムの機能を調べるツールに置き換えられました。

通常、プローブ コードを configure.ac ファイルに記述し、autoconf コマンドを実行して、このファイルを、使用した実行可能 configure コマンドにコンパイルします。

したがって、実行すると./configure && make、システムで利用可能な機能を調べ、検出された構成で実行可能ファイルをビルドします。

オープンソース プロジェクトがソース コード コントロール システムの使用を開始したとき、configure.ac ファイルをチェックインするのは理にかなっていますが、コンパイルの結果 (configure) をチェックインするのは理にかなっています。autogen.sh は、適切なコマンド引数を使用して autoconf コンパイラーを呼び出す小さなスクリプトにすぎません。

--

Automake はコミュニティの既存の慣習からも生まれました。GNU プロジェクトは Makefile のターゲットの標準セットを標準化しました。

  • make allプロジェクトを構築する
  • make cleanプロジェクトからコンパイルされたすべてのファイルを削除します
  • make installソフトウェアをインストールする
  • make dist配布用のソースを準備しmake distcheck、結果が完全なソースコードパッケージであることを確認するなどです。
  • 等々...

何度も繰り返される定型文が多数存在したため、準拠した makefile の作成は面倒な作業になりました。そこで、Automake は autoconf と統合され、「ソース」Makefile (Makefile.am という名前) を Makefile に処理して Autoconf に渡すことができる新しいコンパイラになりました。

automake/autoconf ツールチェーンは、実際には他のヘルパー ツールをいくつか使用しており、他の特定のタスク用の他のコンポーネントによって拡張されています。これらのコマンドを順番に実行することの複雑さが増すにつれて、すぐに実行できるスクリプトの必要性が生まれ、そこから autogen.sh が生まれました。

私の知る限り、Gnomeはこのヘルパースクリプトautogen.shの使用を導入したプロジェクトでした。

答え2

この分野には、Cmake と GNU Autotools という 2 つの「大手」が存在します。

  • GNU Autotools は GNU のやり方で、*nix にかなり重点を置いています。これは一種のメタビルド システムで、実行しようとしていることに対して特定の構成と make ファイルを生成するツール セットを提供します。これにより、ビルド システムを直接操作しなくてもコードにさらに多くの変更を加えることができるようになり、*nix では、設計されていない方法で他の人がコードをビルドできるようになります。

  • Cmake は、クロスプラットフォームな方法です。Cmake チームは、GCC、Visual Studio、XCode、Windows、OSX、Solaris、BSD、GNU/Linux など、さまざまな方法でソフトウェアを構築しています。コード ベースの移植性に少しでも関心がある場合は、これが最適な方法です。

すでに述べたように、Scons を好む人もいるようです。Python に精通している場合は、作業環境の一貫性が向上する可能性があります。

Ruby には Rake と呼ばれる一種のメタビルド システムもあります。これはそれ自体非常に優れており、すでに Ruby に慣れている人にとっては非常に便利です。

答え3

スコンズは代替案の 1 つですが、個人的には経験がありません。また、Python で実装されているため、ビルド環境によっては問題が発生する可能性があります。

答え4

C# の場合は、xbuild (および Windows では msbuild) を使用して、プロジェクト ファイルからプロジェクトをビルドできます。

関連情報