Next: Libtool paradigm, Previous: Top, Up: Top
これまで,ソースコードパッケージの開発者が共有ライブラリの能力を利用し たい場合,パッケージを実行するそれぞれのプラットフォームに対し,カスタ ムサポートコードを書く必要がありました.パッケージインストーラがビルド されるライブラリの種類を選択できるように,コンフィグレーションインター フェースを設計する必要もありました.
GNU Libtoolは,一つのスクリプトでプラットフォーム特有の依存性とユーザ インターフェースの両方をカプセル化することで,開発者の仕事を単純にしま す.GNU Libtoolは,それぞれのホストの形式の完全な機能を,一般的なイン タフェースを通して利用できるが,やっかいな癖はプログラマから隠されるよ うに設計されています.
GNU Libtoolの一貫したインターフェースは再保証されます... ユーザは
好みのソースコードパッケージを共有ライブラリにビルドするため,不明瞭な
ドキュメントを読む必要がありません.パッケージのconfigure
スクリ
プト(またはその同等品)を実行するだけで,libtoolがいやな仕事をすべて行っ
てくれます.
このドキュメント全体にいくつかの例があります.すべて同じ環境を仮定して います.我々は,ライブラリlibhelloを一般的な方法でビルドしたい と思っています.
libhelloは,共有ライブラリ,スタティックライブラリ,または,そ の両方になります... libtoolで移植できるホストシステムで利用可能な すべてのものです.
この章では,libtoolの最初の設計思想を説明します.歴史に興味がなかった り,堅実な方法で拡張されているlibtoolのコードを書きたい場合,自由に飛 ばして次の章へ行ってください.