いろいろ考えたけど、既存のFFI機構は一旦捨てて、PythonとかRuby等他の処理系でも実装できる形でやりなおす事にした。今回は3つのScheme処理系を選んで、そこである程度作りこんだ後他のScheme処理系に広げる方向にする。

Chez Scheme: JITC型の処理系(R6RS)。このため、Scheme側だけでFFIを実装できる。今回はこれで基本的なPC上のプロトタイプを済ませる。
Gauche: 有名なSchemeインタプリタ(R7RS)。処理系側にはlibffiのような機構が無いため言語拡張を書いて統合する必要がある。この処理系で移植性の確認をする。
Ribbon: 自作の処理系(yuni)。デバッグ機能が一切無いので、基本的に既存のScheme処理系である程度完成させたアプリケーションを動作させることを想定している。

AndroidやiOSのようなモバイルプラットフォームでは基本的にRibbonを使う。

`union` 化

今までは関数のパラメタは uint64_t の配列として渡していたが、これだと浮動小数点を uint64_t* 整数ポインタにキャストして代入することになり、strict type aliasing ruleに反する。というわけで union に格納することにした。

NCCCはNormalized C Calling ConventionなのでC++のサポートについては気にしないことにする。

動的ライブラリを配置する

add_custom_target でコピーすることにした。最初 add_custom_command の POST_BUILD でやろうと思ってたけど、そういやこれ sub directory で追加されたターゲットには実行できないんだった。

Make directoryは1回で良いな。。というか、mkdirは本来はCMakeの実行時じゃなくてビルド時にやる方が正しい気はする。面倒なので普通に file(MAKE_DIRECTORY ...) で済ますけど。

まぁ出てあたりまえなんだよなぁ。。とりあえずデスクトップアプリを作るのに必要な機能(VSYNCまちとかタイマとか)をyuniframe側に加えて何かアプリを作ってみるのが良いかな。