libtool は実質的に *.so （ウインドウズで言う所の *.dll のようなもの）をビルドする書式を共通化するためのものだけど、
./configure を生成する autoconf, automake は、システムのタイプを判断する作業から、プログラマーを開放してくれるから、使った方が便利。

面倒くさいのでもう343のように詳しくは書かないが、（どうせ誰かが書いてくれるだろう。）

例えば、引数で受け取った画像を拡大縮小して、ファイル出力するツール|ライブラリを書く場合。

画像処理は（たとえば単純にバイリニアだとして）、
画像をブロック毎に分割して処理を行えば、完全に並列処理できる類の問題だよな？（アムダールの法則の1/(F-(1-F))のFが非常に小さい状態）
だからスレッドに分割して、多コアに割り当てて、一気に高速計算するべき。

この際に、無駄なスレッドを作ると、逆に速度が遅くなる。
例えば、プロセッサのコア数が４だとしたら、スレッドも４個にするのが最も効率が良い。（コア数が４なのにスレッドを８個とか作っても、無駄だし、スイッチングロスで逆に遅くなる）

このプロセッサー数を、実行時に判断することもできるのだが、それだとビルド時の決め打ちによる強力な最適化を書くことができない。
そこで、定数としてビルド時にコア数を知っとくことは、性能を追求する場合において、とても有用。

そこで、ビルド時にコア数を知りたいという要求が出てくるのだが、この「コア数を知る」という方法が、OSやCPUなどによって、それぞれ全然変わってくる。
これに全パターン対応するMakefileを書くのは、非常に負担となるので、ここを共通の書式で自動化してくれるのが autoconf の役割。
たとえばプロセッサー数ならば configure.in に AX_COUNT_CPUS と一行書いておけば、（もし指定してあれば）config.hに #define CPU_COUNT 4 等のようにマクロ定義される。これを利用してコードをを最適化できる。
(AX_COUNT_CPUSのm4マクロによって（autoconf archive要インストール）)

CPU数に限らず、ベクトル演算のサポートの有無など、事前に調べて最適化に有用な情報を、容易に得る手段として、autoconfは非常に便利なので使った方がいい。
autoconfで実行環境情報を積極的に得るようにすれば、プログラム最適化の幅が広がるはず。