Gauche:ABICompatibility

Gauche:ABICompatibility

Shiro(2009/11/23 18:21:34 PST): ABI互換性について気をつけることメモ。

目的

Gaucheのmicro version up (X.Y.Z の Z が変わる変更) については、 Gaucheを入れ替えるだけで拡張ライブラリなどlibgauche.soに依存するものは そのまま使えるようにしたい。

考慮すべきは以下の点。

新しいAPIの追加は許す。つまり、コアを 0.9 -> 0.9.1 にした時:

ライブラリのロードパス

一番簡単なのはロードパス中のバージョン番号埋め込みをmajorとminor (X.Y) だけに することだな。

ただ、この場合、既にGaucheが入ってるところに上書きインストールすると、 既に ${exec_prefix}/lib/gauche/X.Y/ 以下に作られている階層に 上書きすることになる。それはそれでちょっと気持ち悪い。 特に、何か問題が出てダウングレードしたい場合に困りそうだ。 (この階層にはGauche-gl等コア以外のモジュールの.soも入ってるので、 どれとどれを旧バージョンに戻したら良いのかすぐにわからない、とか)

バージョンX.Y.ZのコアはZを一個づつ減らしたパスを全部load-pathに 入れちゃうって手もある。これだと今と同じディレクトリ構造で、 さらに旧バージョン向けにコンパイルされた拡張ライブラリも見える。 でもmicro versionが増えるとロードパスがやたらに長くなるし、 うっかり古いの消したら今使ってる拡張ライブラリも消えちゃったって ことになりそうだ。

少々強引なハックだけれど、Gaucheコアインストール時に 旧バージョン用のディレクトリがあったらコア以外の.soを新バージョンディレクトリから ハードリンクしてしまうってのはどうだ。 インストール時の操作がややこしくなるが、特に問題は生じないような気もする。 (ハードリンクが使えないOSではコピーすることになるのがちょっと嫌かも しれないが)。 これを試してみよう。

いや、だめだ。拡張パッケージが何らかのパッケージマネージャで管理されてる場合、 コピーやハードリンクしちゃうとパッケージマネージャからのアンインストールで ファイルが消えてくれなくなる。

要求事項をまとめてみる。

ってことは、アーキテクチャ依存ファイルの置き場を こうしてみたらどうだろう。

今はGauche-glのファイルとかがsiteじゃない方(本体と一緒)に入ってるけど、 本体以外のは全部siteに入れることにする。

アーキテクチャ非依存の方はディレクトリ構成は今までどおりとして、 本体以外のは全部site以下に入れる、という点だけ変更する。

拡張ライブラリからのバージョンチェック

初期化ルーチンがマクロSCM_INIT_EXTENSIONを呼んでるので、 マクロ定義をちょっといじってABI versionのチェックを忍ばせることは できそうだ。

mainからのバージョンチェック

Scm_Init()に渡してるsignatureにバージョンが含まれるので、 それを解析してチェックする。

gauche versionとabi version

ABI_versionはどのように指定するのが良いか。

案1の方が 一見わかりやすそうではあるのだけれど、 よく考えるとそうでもない。

まあsonameについては、gauche_version X.Yをlibgauche-X.so.Y にマップしてしまう、 という手が無くはない。

案2については、プレリリースの0.99でABIバージョン1を実装する、というような 融通がきかせられるという利点がある。(あと、どうしてもmicro version upで ABIを変更せざるを得ない止むに止まれぬ事情があった場合、とか。)

折衷案でこういうのはどうだ(案3)。

major.minorまでをそんなに頻繁にアップデートするとも思えないので、 ${exec_prefix}以下にディレクトリが無闇に増殖してしまうってことは多分ないだろう。

More ...