朗報です! GNU Autotoolsは、あなたが思っているよりもセットアップがはるかに簡単で、GNUAutotools自体が1,000行の構成ファイルを生成します。はい、20行または30行のインストールコードを記述して、残りの4,000行を無料で入手できます。
Linuxターミナル
- Linux用の上位7つのターミナルエミュレータ
- Linuxでのデータ分析のための10個のコマンドラインツール
- 今すぐダウンロード:SSHチートシート
- 高度なLinuxコマンドのチートシート
- Linuxコマンドラインチュートリアル
Linuxを初めて使用するユーザーで、アプリケーションのインストール方法に関する情報を探している場合は、この記事を読む必要はありません。ソフトウェアがどのように構築されているかを調べたい場合は、これを読んでもかまいませんが、新しいアプリケーションをインストールするだけの場合は、Linuxへのアプリのインストールに関する私の記事を読んでください。
開発者にとって、Autotoolsは、ユーザーがソフトウェアをコンパイルおよびインストールできるように、ソースコードを管理およびパッケージ化するための迅速かつ簡単な方法です。 Autotoolsは、DEBやRPMなどの主要なパッケージ形式でも十分にサポートされているため、ソフトウェアリポジトリのメンテナはAutotoolsで構築されたプロジェクトを簡単に準備できます。
Autotoolsは段階的に機能します:
- まず、 ./ configureの間 ステップで、Autotoolsはホストシステム(それが実行されているコンピューター)をスキャンしてデフォルト設定を検出します。デフォルト設定には、サポートライブラリの場所、および新しいソフトウェアをシステムに配置する場所が含まれます。
- 次に、作成中に ステップ、Autotoolsは、通常、人間が読めるソースコードを機械語に変換することによってアプリケーションを構築します。
- 最後に、インストールの作成中に ステップ、Autotoolsは、ビルドしたファイルをコンピューター上の適切な場所(構成段階で検出されたもの)にコピーします。
Autotoolsを使用している限り、このプロセスは単純に見えます。
GNU Autotoolsは、私たちのほとんどが当然のことと思っている大きくて重要なソフトウェアです。 Autotoolsは、GCC(GNUコンパイラコレクション)とともに、実行中のシステムにフリーソフトウェアを構築してインストールできるようにする足場です。 POSIXシステムを実行している場合、これらのプロジェクトのために、ほとんどのオペレーティングシステムがコンピューター上で実行可能なソフトウェアとして存在していると言っても過言ではありません。
ペットプロジェクトがオペレーティングシステムではない可能性が高い場合は、Autotoolsがニーズに対してやり過ぎだと思われるかもしれません。しかし、その評判にもかかわらず、Autotoolsには、プロジェクトが比較的単純なアプリケーションまたは一連のスクリプトであっても、役立つ可能性のある小さな機能がたくさんあります。
まず第一に、Autotoolsは移植性を念頭に置いています。プロジェクトをすべてのPOSIXプラットフォーム(コーダーとしてのあなた次第)で機能させることはできませんが、Autotoolsは、インストール用にマークしたファイルが既知のプラットフォーム上の最も適切な場所にインストールされるようにすることができます。また、Autotoolsのおかげで、パワーユーザーが自分のシステムに応じて、最適でない値をカスタマイズしてオーバーライドするのは簡単です。
Autotoolsを使用する場合、知っておく必要があるのは、どのファイルをどの一般的な場所にインストールする必要があるかだけです。それは他のすべての面倒を見ます。テストされていないOSで機能しないカスタムインストールスクリプトはもうありません。
Autotoolsも十分にサポートされています。 Autotoolsを使用してプロジェクトをディストリビューションパッケージャーに渡します。RPM、DEB、TGZなどをパッケージ化する場合でも、その作業は簡単です。パッケージングツールはAutotoolsを認識しているため、パッチ適用、ハッキング、調整は必要ない可能性があります。多くの場合、Autotoolsプロジェクトをパイプラインに組み込むことも自動化できます。
Autotoolsを使用するには、最初にAutotoolsをインストールする必要があります。ディストリビューションは、開発者がプロジェクトを構築するのに役立つ1つのパッケージを提供する場合もあれば、コンポーネントごとに個別のパッケージを提供する場合もあるため、インストールする必要のあるパッケージを見つけるために、プラットフォームで調査を行う必要がある場合があります。
Autotoolsの主なコンポーネントは次のとおりです。
- 自動作成
- autoconf
- 作成
プロジェクトに必要なコンパイラ(GCCなど)をインストールする必要があるかもしれませんが、Autotoolsは、コンパイルする必要のないスクリプトやバイナリアセットで問題なく動作します。実際、Autotoolsはアンインストールを行うを提供するため、このようなプロジェクトに役立ちます。 簡単に削除できるスクリプト。
すべてのコンポーネントをインストールしたら、プロジェクトのファイルの構造を確認します。
GNU Autotoolsには非常に具体的な期待があり、ソースコードを頻繁にダウンロードしてビルドする場合、それらのほとんどはおそらくおなじみです。まず、ソースコード自体は srcというサブディレクトリにあると予想されます 。
プロジェクトはこれらの期待のすべてに従う必要はありませんが、(Autotoolsの観点から)非標準の場所にファイルを配置する場合は、後でMakefileで調整する必要があります。
さらに、次のファイルが必要です:
- ニュース
- README
- 作成者
- ChangeLog
ファイルを積極的に使用する必要はなく、モノリシックドキュメント( README.md など)へのシンボリックリンクにすることができます。 )そのすべての情報を網羅していますが、それらは存在している必要があります。
configure.acというファイルを作成します プロジェクトのルートディレクトリにあります。このファイルはautoconfによって使用されます 構成を作成するには ユーザーがビルドする前に実行するシェルスクリプト。ファイルには、少なくとも AC_INITが含まれている必要があります およびAC_OUTPUT M4マクロ。これらのマクロを使用するために、M4言語について何も知る必要はありません。それらはすでに作成されており、Autotoolsに関連するものはすべてドキュメントで定義されています。
お気に入りのテキストエディタでファイルを開きます。 AC_INIT マクロは、パッケージ名、バージョン、バグレポートの電子メールアドレス、プロジェクトURL、およびオプションでソースTARファイルの名前で構成されます。
AC_OUTPUT マクロははるかに単純で、引数を受け入れません。
AC_INIT([penguin], [2019.3.6], [[email protected]])
AC_OUTPUT
autoconfを実行する場合 この時点で、構成 スクリプトはconfigure.acから生成されます ファイル、そしてそれは正常に実行されます。ただし、これまでに行ったのは、プロジェクトのメタデータを定義し、構成スクリプトを作成するように要求することだけなので、これですべてです。
configure.acで呼び出す必要のある次のマクロ fileは、Makefileを作成するための関数です。 Makefileはmakeに通知します 何をすべきか(通常、プログラムをコンパイルしてリンクする方法)を指示します。
Makefileを作成するためのマクロはAM_INIT_AUTOMAKEです。 、引数を受け入れない、および AC_CONFIG_FILES 、出力ファイルを呼び出す名前を受け入れます。
最後に、プロジェクトに必要なコンパイラを説明するマクロを追加する必要があります。使用するマクロは明らかにプロジェクトによって異なります。プロジェクトがC++で記述されている場合、適切なマクロは AC_PROG_CXXです。 、Cで記述されたプロジェクトには AC_PROG_CCが必要です。 Autoconfドキュメントの「プログラムとライブラリの構築」セクションで詳しく説明されているように、など。
たとえば、C++プログラムに次を追加する場合があります。
AC_INIT([penguin], [2019.3.6], [[email protected]])
AC_OUTPUT
AM_INIT_AUTOMAKE
AC_CONFIG_FILES([Makefile])
AC_PROG_CXX
ファイルを保存します。 Makefileに移りましょう。
AutotoolsMakefileの生成
Makefileを手動で作成することは難しくありませんが、Autotoolsが作成し、生成するものは./configure
中に検出された構成オプションを使用します。 ステップ、そしてそれはあなたが自分で書きたいと思うよりもはるかに多くのオプションを含みます。ただし、Autotoolsはプロジェクトのビルドに必要なすべてを検出できないため、ファイル Makefile.amに詳細を追加する必要があります。 、これは automakeによって使用されます Makefileを作成するとき。
Makefile.am はMakefileと同じ構文を使用するため、Makefileを最初から作成したことがある場合、このプロセスは使い慣れたシンプルなものになります。多くの場合、 Makefile.am ファイルに必要な変数定義は、ビルドするファイルとインストールする場所を示すために必要なものだけです。
_PROGRAMSで終わる変数 ビルドするコードを特定します(これは通常、プライマリと見なされます 目標;これがMakefileが存在する主な理由です)。 Automakeは、 _SCRIPTSなどの他のプライマリを認識します 、 _DATA 、 _LIBRARIES 、およびソフトウェアプロジェクトを構成するその他の一般的な部分。
アプリケーションがビルドプロセス中に文字通りコンパイルされる場合は、 bin_PROGRAMSを使用してアプリケーションをバイナリプログラムとして識別します。 変数を作成し、プログラム名を変数プレフィックスとして使用して、ソースコードのビルドに必要な部分(これらの部分はコンパイルおよびリンクされる1つ以上のファイルの場合があります)を参照します。
bin_PROGRAMS = penguin
penguin_SOURCES = penguin.cpp
bin_PROGRAMSのターゲット bindirにインストールされます 、コンパイル中にユーザーが構成できます。
アプリケーションが実際にコンパイルされていない場合、プロジェクトには bin_PROGRAMSは必要ありません。 まったく可変。たとえば、プロジェクトがBash、Perl、または同様のインタプリタ言語で記述されたスクリプトである場合は、 _SCRIPTSを定義します。 代わりに変数:
bin_SCRIPTS = bin/penguin
Automakeは、ソースが srcというディレクトリにあることを想定しています。 したがって、プロジェクトでレイアウトに代替のディレクトリ構造を使用する場合は、外部ソースからのコードを受け入れるようにAutomakeに指示する必要があります。
AUTOMAKE_OPTIONS = foreign subdir-objects
最後に、 Makefile.amでカスタムMakefileルールを作成できます 生成されたMakefileに逐語的にコピーされます。たとえば、インストールを進める前にソースコードで一時的な値を置き換える必要があることがわかっている場合は、そのプロセスのカスタムルールを作成できます。
all-am: penguin
touch bin/penguin.sh
penguin: bin/penguin.sh
@sed "s|__datadir__|@datadir@|" $< >bin/$@
特に便利なトリックは、既存のクリーンを拡張することです。 少なくとも開発中はターゲット。 きれいにする コマンドは通常、Automakeインフラストラクチャを除くすべての生成されたビルドファイルを削除します。ほとんどのユーザーがきれいにすることを望んでいないため、このように設計されています コードの作成を容易にするファイルを消去します。
ただし、開発中に、プロジェクトをAutotoolsの影響を比較的受けない状態に確実に戻す方法が必要になる場合があります。その場合は、これを追加することをお勧めします:
clean-local:
@rm config.status configure config.log
@rm Makefile
@rm -r autom4te.cache/
@rm aclocal.m4
@rm compile install-sh missing Makefile.in
ここには多くの柔軟性があり、Makefileにまだ慣れていない場合は、 Makefile.amが何であるかを知るのが難しい場合があります。 ニーズ。最重要事項は、それがバイナリプログラムであるかスクリプトであるかにかかわらず、主要なターゲットであり、ソースコードがどこにあるかを示します( _SOURCES を介しているかどうか)。 変数またはAUTOMAKE_OPTIONSを使用 Automakeにソースコードを探す場所を指示します。
これらの変数と設定を定義したら、次のセクションに示すようにビルドスクリプトを生成して、不足しているものを調整することができます。
Autotoolsビルドスクリプトの生成
インフラストラクチャを構築したので、今度はAutotoolsに最高の機能を実行させます。プロジェクトツールを自動化します。開発者(あなた)がAutotoolsとインターフェースする方法は、コードを作成するユーザーが行う方法とは異なります。
ビルダーは通常、このよく知られたシーケンスを使用します:
$ ./configure
$ make
$ sudo make install
ただし、その呪文が機能するためには、開発者としてのあなたがビルドインフラストラクチャをブートストラップする必要があります。まず、 autoreconfを実行します makeを実行する前にユーザーが呼び出すconfigureスクリプトを生成します 。 –インストールを使用します depcompへのシンボリックリンクなどの補助ファイルを取り込むオプション 、コンパイルプロセス中に依存関係を生成するスクリプト、およびコンパイルのコピー スクリプト、構文の差異を考慮したコンパイラのラッパーなど。
$ autoreconf --install
configure.ac:3: installing './compile'
configure.ac:2: installing './install-sh'
configure.ac:2: installing './missing'
この開発ビルド環境を使用すると、ソースコード配布用のパッケージを作成できます。
$ make dist
遠い targetは、Autotoolsから「無料」で取得するルールです。
これは、謙虚な Makefile.amから生成されたMakefileに組み込まれる機能です。 構成。このターゲットはtar.gzを生成します パッケージをダウンロードする人がプロジェクトをビルドできるように、すべてのソースコードとすべての重要なAutotoolsインフラストラクチャを含むアーカイブ。
この時点で、アーカイブの内容を注意深く確認して、ユーザーに出荷する予定のすべてのものが含まれていることを確認する必要があります。もちろん、それから自分で構築してみてください:
$ tar --extract --file penguin-0.0.1.tar.gz
$ cd penguin-0.0.1
$ ./configure
$ make
$ DESTDIR=/tmp/penguin-test-build make install
ビルドが成功すると、 DESTDIRで指定されたコンパイル済みアプリケーションのローカルコピーが見つかります (この例の場合、 / tmp / penguin-test-build 。
$ /tmp/example-test-build/usr/local/bin/example
hello world from GNU Autotools
Autotoolsは、予測可能で自動化されたリリースプロセスのためのスクリプトの優れたコレクションです。このツールセットは、PythonまたはBashビルダーに慣れている場合は初めての場合もありますが、プロジェクトに提供される構造と適応性について学ぶ価値があると思われます。
また、Autotoolsはコードだけのものではありません。 Autotoolsは、Docbookプロジェクトの構築、メディアの整理(音楽リリースにはAutotoolsを使用)、ドキュメントプロジェクト、およびカスタマイズ可能なインストールターゲットの恩恵を受ける可能性のあるその他すべてに使用できます。