autoconfとその仲間達は,通常様々なUnixで実行されますが,それは その他のシステムでも使用され,最も顕著なものとしてはDOSの仲間 があげられます.このことは,ファイルとパス名に関する仮定に衝突します.
例えば,以下のようなコードを考えます.
case $foo_dir in /*) # Absolute ;; *) foo_dir=$dots$foo_dir ;; esac
それらのシステムではドライブスペックを使用していて,通常はディレクトリの 分離子としてバックスラッシュを使用しているため,絶対パスを正しく検出する ことに失敗するでしょう.絶対パスに対する調査の標準的な方法は以下のとおり です.
case $foo_dir in [\\/]* | ?:[\\/]* ) # Absolute ;; *) foo_dir=$dots$foo_dir ;; esac
適切な場合は角カッコの引用符で囲み,最初の文字としてのバックスラッシュを 保持していることを確認してください(see Limitations of Builtins).
また,コロンがデバイス指定の一部として使用されているので,これらのシステ
ムではそれをパスの分離子として使用していません.パスを作成しているときや
パスにアクセスしているときは,代わりにPATH_SEPARATOR
出力変数を使
用してください.configureは,開始時にこれを適切な値(‘:’
または‘;’)に設定します.
ファイル名にも余計な注意が必要になります.(DJGPPのような) autoconfを十分に実行できるUnixのようなDOSベースの環 境では,通常長いファイル名を適切に扱うことが可能ですが,パッケージを壊し てしまう深刻な制限も残っています.これらの問題のいくつかは, doschk パッ ケージで容易に検出することが可能です.
以下は簡単な全体像です.問題には,適用を示すためsfn/lfnで印が ついています.sfnは,Windows下のDOS窓ではなく,プレーンな DOSにのみ関連する問題を意味し,一方lfnは,Windowsでも存在 する問題を意味しています.
以下はUnix上では完全にOKです.
AC_CONFIG_HEADERS([config.h]) AC_CONFIG_FILES([source.c foo.bar]) AC_OUTPUT
しかし,それは‘config.h.in’,‘source.c.in’,そして ‘foo.bar.in’が必要になるので,DOSでは問題があります.パッ ケージをDOSベースの環境でより移植性を高くするため,その代わり に以下を使用すべきです.
AC_CONFIG_HEADERS([config.h:config.hin]) AC_CONFIG_FILES([source.c:source.cin foo.bar:foobar.in]) AC_OUTPUT
注意:これは通常,ファイル名をユニークにするために短いバージョンでは数字
の後置を使用するので,Windowsでは問題になりません.しかし,レジストリの
設定でこの動作を停止可能です.これで長いファイル名を含むファイルのツリー
を,sfnとlfnの環境で共有することが可能になりますが,上記の問題
は同様に存在します.