Previous: Other implementations, Up: Introduction


1.4 その他の実装の近代的な解析

調査されたそれぞれの実装は,多くの異なるホストシステムに対して,予定し ていた仕事をすべて公平に行いました.しかし,再利用できるコンポーネント として一般的に機能するものは,これらの解決法にはないようでした.

ほとんどのものは,実装で行なわれていることを正確に理解すること無く使用 する(まして,変更する)には複雑すぎ,それらは通常,文章化されていません でした.

異なるベンダーはライブラリについて異なる見解を持つこと,そして,当然 動作するという単一のパラダイムを自信を持って定めているものが調 査したパッケージには無かったことが主な難点です.

理想としては,既存のライブラリシステムが一貫して動作するような一連の拡 張と変更として実装されている標準物に,libtoolがなることです.しかし, オペレーティングシステム開発者に悪い方法を修正させることは簡単な仕事で はなく,バグが多く,壊れていて,混乱したオペレーティングシステム上でさ え,今すぐに共有ライブラリをビルドしたいと,人々は思っていました.

このため,libtoolは独立したシェルスクリプトとして設計されました.それ は,異なるプラットフォーム上のコンパイラスイートを,堅実で強力なインター フェースを用いて包み隠すことで,Makefileの書き手を悩ませるライ ブラリのビルドでの問題と矛盾から隔離しています.

運が良ければ,libtoolは役に立ち,GNUコミュニティで使用され,そして,そ れを書くとき学んだ教訓は,将来のライブラリシステムの設計に採用されるで しょう.