プログラミング

システムエンジニア回顧録｜configureの向こう側。ソースから組み立てる前の準備

Autoconf・Automakeの参考リンクメモと2002年のApache導入記録から、configure、ビルド、導入の段階を振り返ります。鹿のメイザーが、短い操作列の向こうにある準備を語ります。

この回を動画で見る

同じテーマを、鹿のメイザーが図解と字幕付きで語ります。

鹿のメイザーの解説をYouTubeで見る

参考リンクと2002年の導入メモ

どうも、鹿のメイザーです。今日はソースからソフトを組み立てる前の準備のお話じゃ。昔の資料を開くと、configure、make、installという短い名前が並んでいます。三つの呪文で何でも完成、と言いたくなるが、呪文の前にも確かめることがあったんですね。

主資料は、AutoconfとAutomakeの参考リンクを残した短いメモです。これだけでは、わしが使いこなした日や成功した結果は分かりません。そこで今回は、二千二年二月のApache導入メモも合わせて、操作の記録と、今調べた仕組みを分けて眺めます。

その導入メモには、configureを使う手順と、envのスペルミスでエラーになった記録が残っています。何時間苦しんだか、最後にどんな成果を出したかは書かれていません。小さな入力の違いと、準備の意味を取り出す回顧録じゃ。大盛りの成功談にはしないでおこう。

configureは準備の工程

configureは、そこで使える機能などを調べ、ビルドのための設定を整える工程です。GNUの公式説明でも、Makefileなどのファイルを作る役割が示されています。台所で材料と道具を確かめ、段取りを決めるようなものじゃ。ここで料理が全部出来上がるわけではありません。

画面の文字が次々に流れると、何か大きなことが進んでいる気がします。実際に検査は進むのじゃが、何の工程が終わったのかを分けて読む必要があります。準備が終わったことと、その後のコンパイルや導入まで終わったことは、それぞれ確かめる場面なんですね。

古いメモに短い操作列だけが残っていても、工程名を添えると読み直しやすくなる。まず前提を調べる、次に組み立てる、その後使う場所へ配置する。全部を同じ成功の印にしない。昔の自分が何を期待してその操作をしたのか、説明するための見取り図になります。

道具を作る側と使う側

名前が似ているので、Autoconfとconfigureを同じ道具として覚えたくなりますね。でも、Autoconfはconfigureを生成する側の道具です。配布されたソフトを組み立てる人が、そのconfigureを実行する場面とは役割が違う。設計図を用意する仕事と、それを使う仕事を分けよう。

公式資料では、configure.acという入力からconfigureを作る流れが説明されています。古い資料ではconfigure.inという名前も見掛けます。今回のメモには詳しい生成操作の実績はないので、本人がそのファイルを書いた話にはしません。資料の名前を、仕組みの説明へつなぐ補足です。

利用者がいつも生成用の道具を全部動かすとは限りません。配布物に何が含まれているか、開発中のソースを扱っているのかでも準備が変わります。道具を増やす前に、自分はいまどちら側の仕事をしているのかを見る。道具箱が重くなる理由も、少し整理できるんじゃね。

Makefileへ環境を伝える

Automakeの公式説明では、Makefile.amなどの入力を使ってMakefile.inを作る流れが示されています。そこからconfigureの工程で設定が反映され、Makefileが作られる。名前の末尾だけが少し違うファイルが並ぶので、初めて見ると、親戚の集まりのようじゃ。

今回の図では、テンプレート、環境の反映、作業の指示という三つの箱にしました。実際のファイルを写したものではありません。何を入力にして何を作るかを読むための図です。ファイル名を一つずつ暗記する前に、流れの中の役割を置いてみたいんじゃね。

作られたMakefileは、ソフトの完成品そのものではありません。そこから行う作業の指示として使われます。名前の中にmakeがあるから、もう組み立て済みと思わないようにしたい。段取り表が机に載ったことと、机の上の仕事が終わったことには、間があるんです。

envの入力で立ち止まる

二千二年の導入メモには、envを付けてconfigureを実行した記録と、そのenvのスペルミスでエラーになった説明があります。難しい仕組みを調べているときにも、入口の短い単語で立ち止まることがある。たった三文字が、意外に存在感を発揮するんじゃ。

envの役割は、指定した環境でコマンドを実行することです。元メモには具体的な指定も残っていますが、今回そのまま再掲したり、何でも速くなる設定と紹介したりはしません。何を、どの実行へ渡したかったのか。その範囲を理解するところに話を絞ります。

この記録から、どんなエラー文が出たかや、修正後の詳細な結果までは分かりません。そこを作らなくても、入力を見直す入口は見える。大きなソフトの設定を疑う前に、いま実行しようとした名前と引数を読んでみる。小さな確認にも、仕事があるんじゃね。

config.logを手掛かりにする

ここからは、現在の公式資料で確かめた補足です。configureにはconfig.logというログがあり、コンパイラなどが出したメッセージが、調べる手掛かりになります。今回の本人のメモに、そのログを解析して解決した実績がある、と言っているわけではありません。

ログを読むときは、どの検査のために何を実行し、どんな条件でその出力が出たかを見る。最後に見えた短い文だけで、原因をすぐに決めない。地図の端にある一つの印だけで、森全体の様子を決めるのは難しいじゃろう。前後の情報を合わせて読むための資料なんですね。

そしてログには、環境の情報やファイルの場所が入ることがあります。誰かへ相談するときも、そのまま全部貼り付ける前に内容を確認したい。今回の図と字幕には、原本のパソコン名や私有パスを使いません。必要な技術情報だけを、匿名の概念図として残しています。

準備・ビルド・導入を分ける

古い導入メモには、configure、make、make installという並びがあります。今回の図は、準備、組み立て、導入と読み替えて眺めます。短い操作列のままにしておくより、どの段階の何を確認するかが見える。三つの箱には、それぞれ別の仕事が入っているんじゃ。

すべてのソフトが同じ手順を使うわけではありません。必要なものや操作は、対象の版と説明書を確認します。古いメモを読む目的は、当時の段取りを理解すること。現在のソースを入手して、そのまま一括実行する実演にはしません。対象が変われば、前提も読み直す必要がありますね。

どの工程で止まったかが分かると、調べる場所も小さくできます。準備の検査なのか、組み立てなのか、配置なのか。全部をインストールできないという一文で片付けず、いまの地点を一つ残す。細かなメモが、後の自分への道しるべになるところじゃ。

2018年の環境準備の記事へつなぐ

関連資料として、ソフトウェアデザイン、二千十八年二月号を紹介します。石本敦夫さんによる、パッケージ管理の基礎を知ろうという章です。Pythonの環境やパッケージ管理を扱う記事で、確認した開始ページは十八ページ。Autoconfの解説記事として紹介するものではありません。

言語の版や利用するパッケージを切り替えて開発するための道具を扱い、環境の準備に目を向ける入口です。今回の古い導入メモとは道具が違いますが、何を使って、どんな条件で実行するかを理解する、という問いを並べてみたい。後年に確認した関連資料としての紹介じゃ。

二千二年にこの号を読んだ、という体験にはしません。年月号、著者、章、出版社、ページと公式目次を参考資料に残し、短く独立して紹介します。誌面や本文を貼り付けず、興味を持った人が元へ戻れるようにする。道具の違いを消さずに、学ぶ入口をつなぎます。

成功の前に前提を記録する

今日は、参考リンクだけの小さなメモと、二千二年の導入記録を合わせて、ソースから組み立てる前の準備を振り返りました。生成する側と使う側、設定とビルド、ビルドと導入。似ている名前や操作を分けると、長い道順にも目印を付けられるんじゃ。

envの入力で立ち止まった記録にも、確認の入口があります。使った道具の版、実行した工程、確かめた結果を一緒に残す。リンクだけのメモには、読んだ内容と実行した内容の違いも添えたいね。詳しい成功結果がないところは、そのまま残しておくのが、後から読む自分に親切です。

皆さんのメモにも、短い操作列が、そのまま置いてあるでしょうか。今なら何を準備していたのか分かるものも、改めて調べたくなるものもあるはずです。呪文のように見えた文字の向こうに、作業の段取りが見えてくる。今日はそんな入口のお話でした。それではまた、次の技術メモでお会いしましょう。

参考資料

-プログラミング