4.1make によるソースからのビルドとインストール

ディストリビューションのパッケージにまだ収録されていない最新版や、独自にビルドオプションを変えたいソフトウェアは、ソースコードから自分でビルドするしかありません。運用管理者にとって「どこからソースを取り、どう検証し、どう配置するか」を一連の型として押さえることは、専門知識としての土台になります。

4.1.1ソースの取得とバージョン選択

• git clone でリポジトリを丸ごと取得。安定版を使いたい場合はgit tag -lでタグ一覧を確認し、git checkout <tag>で特定のリリースに切り替える。
• 配布サイトから取得したアーカイブは圧縮形式に応じて展開する：gzip/gunzip（.gz）・bzip2（.bz2）・xz（.xz）・tar（まとめて展開／tar xzf等）・unzip（.zip）。
• ベンダー配布のパッチファイルはpatchで当てる（patch -p1 < fix.patch）。ソース展開後・configure 前に適用するのが基本の順序。

4.1.2configure から make install まで

• configure（./configure）は実行環境（コンパイラ・ライブラリ・依存の有無）を検出し、Makefileを生成するスクリプト。--prefix= でインストール先を指定できる。
• make は生成された Makefile に従いソースをコンパイル。続くmake installでバイナリ・マニュアル等を配置先（既定 /usr/local 等）へコピーする。
• 典型的な一連の流れは ./configure && make && make install。configure が依存の欠落を検出した場合はエラーで停止するため、make の前に解消する。

実務での典型シナリオを追うと理解が深まります。最新の安定版を使いたいとき、git clone で取得した直後の作業ツリーは開発中の最新コミットであることが多いため、まず git tag -l でリリースタグ（例 v2.4.1）を確認し、git checkout v2.4.1 で明示的に切り替えます。ベンダーが提供する配布アーカイブ（tarball）を使う場合は、.tar.gz なら tar xzf、.tar.xz なら tar xJf のように圧縮方式に応じたオプションを選びます。展開後、既知の不具合を直すpatchファイルが提供されていれば、cd でソースディレクトリに入ってから patch -p1 < xxx.patch を適用し、その後でconfigureを実行します。configure はコンパイラの有無や依存ライブラリを検査して環境に合った Makefileを作るため、ここで依存不足のエラーが出たら make に進む前に該当パッケージを導入します。最後の make install は多くの場合 root 権限が必要で、/usr/local/bin のようにディストリビューションのパッケージ管理外のパスへ配置されるため、後々のアップデート・アンインストールの手間が増える点も運用上の判断材料です。

4.1.3この節のまとめ

• 取得は git clone / git tag -l / git checkout、展開は圧縮形式に応じ gzip・bzip2・xz・tar・unzip
• 順序は patch → configure（Makefile生成） → make（コンパイル） → make install（配置）