週刊nmosh - string-fill!が無い事件 / 移植計画
なんとこの期に及んでnmoshにはstring-fill!が無いことが発覚した。RacketのR6RS test suiteに何故か無いので見落していたようだ。まぁ普通mutable stringsは使わないんで。。
Solaris
タイムリーにvanilla-moshについてbootstrapの問題が出た( http://d.hatena.ne.jp/mjt/20141018/p1 )が、少々やんごとなき事情により別方向の開発を加速する必要が出てきた。
平たく言えばBoehmGCというかMMUが使えない環境の対応が必要になったためで、とりあえず0.2.8のスケジュールでどこまでが実現可能かを模索することにした。例えば完全なSchemeが動かなくても、FFIでwrapしたC関数がS式で呼べる程度の実装でも良い。目的は自動テストの構築と障害解析で、リソース消費はあまり気にする必要は無い。
開発ホストはSolaris 11(!!)なので、nmosh自体もこの環境に移植する必要が有る。もっとも、SolarisにはLinuxエミュレーションが有るはずなので最悪それでも良い気もするけど。
大学でSolaris8を使って以来なのでさっぱり覚えていない。。そもそもSYSVで動くのかとかマルチスレッドなバイナリをビルドするときに_REENTRANTを明示的に指定しないと不味いとか( http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#SOLARIS_PROBLEMS_AND_WORKAROUNDS )。。
(Luaで良いだろ にならないのは、既にnmoshで構築したGUI等を流用するため。なので、Luaコードや他の組込みスクリプトエンジン向けのコードを生成するライブラリを書くという解決策も一応視野には有る。。)
マルチOSでのビルド環境を考える会
この手の案件が有る度にかかりきりになるのはやっぱり効率悪いので、ポータビリティを意識した開発環境を用意するのは重要。。次の案件はDragonflyBSDかもしれない(そんなことは多分無いが)。
nmoshはbootstrapに非常に多くのツールが必要で、各対応OSでbootstrapするのはあまり現実的でない。今回Solarisに移植するにあたってSolaris上でbootstrapすることを考えると、まずGaucheを動かすところから入らないといけなくなる。(注: 実際にGaucheがsolarisで動くのかは試していない)
基本的な方針としてはLinuxでbootstrapし、それをNFS mountして各OSでビルドするということにする。残念ながらCygwinには良いソリューションが無いが、他のOSでは大抵NFSのマウントはできるため、Linuxでさえbootstrapできれば、re2cやGaucheのような依存ツールを移植する必要はなくなる。副次的なメリットとして、ターゲットOS上でエディタ等の環境を揃える必要もなくなる。。
このシナリオをサポートするには、ビルドシステムとして以下の特徴が必要になる:
- out of treeビルドが可能であること。./configureしたディレクトリ以外でのビルドをサポートし、かつ、ビルドプロセスでソースコードを変更しないこと。
- CMakeのようにこれを前提としたビルドシステムも有る。
- これができないと、各OSでチェックアウトを分けて行い、それぞれでbootstrapする必要が有る。
- out of treeビルドでテストが可能なこと
- ひとつのソースツリーで複数のビルドツリーを保持できること
nmoshではいづれも可能だが、あまり自明な要件でないのでできない処理系も有る。特にconfigureシステムが無くplain Makefileでビルドシステムを構築しているものはサポートしていない傾向にある。
