it-swarm-ja.tech

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

私は時々ソースからアプリをコンパイルし、私はどちらかを使ってきました:

./configure
make
Sudo make install

しかし最近、私は./autogen.shは、configureスクリプトとmakeスクリプトを生成して実行します。

C/C++/C#(mono)コンパイルを効率化する他の方法はありますか?メイクは少し古いようです。新しいツールはありますか?選択を考えると、どちらを使用すればよいですか?

22
Louis Salin

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バージョンでは、「送信」システムコールなどの新機能が導入され、それ以降のオペレーティングシステムではそれが採用されるため、これは重要です。ブランドとバージョンをチェックするコードのスパゲッティを用意する代わりに、開発者は機能ごとに調査を開始したため、コードは次のようになりました。

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

ほとんどのREADMEファイルは、90年代の先のとがった開発者がソースコードをコンパイルしてconfig.hファイルを編集し、システムで使用可能な適切な機能をコメント化するか、標準のconfig.hファイルをそれぞれに出荷するテスト済みのオペレーティングシステム構成。

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

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

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

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

-

Automakeはまた、コミュニティの既存の慣行から成長しました。 GNUプロジェクトは、Makefileの通常のターゲットセットを標準化しました。

  • make allはプロジェクトをビルドします
  • make cleanは、プロジェクトからすべてのコンパイル済みファイルを削除します
  • make installはソフトウェアをインストールします
  • make distmake distcheckのようなものは、配布用にソースを準備し、結果が完全なソースコードパッケージであることを確認します
  • 等々...

何度も何度も繰り返される定型文がたくさんあったため、準拠したメイクファイルを作成するのは重荷になりました。したがって、Automakeは、autoconfと統合され、「ソース」Makefile(Makefile.amという名前)をMakefileに処理してからAutoconfに供給できる新しいコンパイラでした。

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

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

42
miguel.de.icaza

このエリアには2人の「ビッグプレーヤー」がいます。 Cmake、およびGNU Autotools。

  • GNU Autotoolsは、GNU=方法であり、かなり* nixに焦点を合わせています。これは一種のメタビルドシステムであり、特定の構成を生成し、これにより、ビルドシステムを直接操作することなく、コードにさらに変更を加えることができ、* nixの下では、他の人が意図していない方法でコードをビルドすることができます。

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

すでに述べたように、一部の人々はスコンスが好きなようです。 Pythonに精通している場合、これにより作業環境の一貫性が向上する可能性があります。

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

14
Eli Frey

Scons は1つの可能な置換ですが、私は個人的な経験はありません。また、Pythonで実装されているため、ビルド環境によっては問題になる可能性があります。

6
tsvallender

C#/ Monoを使用している場合は、msbuild(MonoDevelopおよびVisual Studioで使用される.sln/.csprojファイル)を使用して、ビルドプロセス全体を管理できます。

その後、MonoDevelopからビルドするか、お気に入りのターミナルでxbuildコマンドを実行します(Mono> = 2.6で最適に動作します)。これは非常に簡単で、MonoDevelopがmsbuildファイルを処理し、MonoDevelopのUIでできることを超えて微調整する必要がない限り、ファイルを編集する必要がないため、ユーザー側でほとんど作業を必要としません。

Msbuildに依存している人々がプロジェクトのインストールをどのように処理するかはよくわかりませんが、いつでも質問できます。 ;-)

3
Sandy

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

0