V8 JavaScript Engineをアプリケーションへ組み込む
JavaScript Engineをアプリケーションへ組み込むために調査をしてみたのだけど古い情報が多かったので、備忘録を残しておこうと思う。
Building V8
環境は、Windows8 + VisualStudio2012 Express for Windows Desktop
まず、SVNの環境を構築する。
個人的には、Gitじゃないのかよ〜という気分だったのだけど、仕方ながないので、TortoiseSVNをインストールした。
ソースコードを取得するだけならGitHubでも公開されているが、ビルド環境を揃えるには、（たぶん）必須となる。
・まずV8のソースコードを下記のアドレスから取得する。
http://v8.googlecode.com/svn/trunk/
・GYPというツールをbuild/gypの配下に取得する。
メインのソースコード以外のビルドに必要な環境は、こんな感じで、個別のフォルダ配下に取得する感じで構築していく。
GYPというのは、Pythonで作ったmakeのようなツールかな？
http://gyp.googlecode.com/svn/trunk
・Pythonをthird_party/python_26の配下に取得する。
最新を取得しても動いたのだけどリビジョン89111が推奨されているらしい。念のためこのリビジョンで取得する。
http://src.chromium.org/svn/trunk/tools/third_party/python_26
・Cygwinをthird_party/cygwinの配下に取得する。
こちらもリビジョン66844が推奨されている。
http://src.chromium.org/svn/trunk/deps/third_party/cygwin
・次のコマンドを実行して、ソリューションファイルを生成する。
build\all.slnファイルが出来上がっていれば成功。結構あっさりと生成される。
third_party\python_26\python.exe build\gyp_v8 -Dtarget=x86 -Dcomponent=static_library
F7ボタンでビルドすれば、次のライブラリファイルが出来上がる。
.\build\Debug\lib\preparser_lib.lib
.\build\Debug\lib\v8_base.lib
.\build\Debug\lib\v8_nosnapshot.lib
.\build\Debug\lib\v8_snapshot.lib
v8_base.lib+v8_nosnapshot.libか、v8_base.lib+v8_snapshot.libの組み合わせで、リンクすれば、JavaScript Engineが使えるようになる。
なぜ2種類に分かれているのかというと高速化の手法に関わりがある。
エンジンの起動を高速化するために初期化済みのメモリのスナップショットを使うのが、v8_snapshot.libらしい。
使い勝手が変わってしまうので、v8_nosnapshot.libも用意されているのだろう。
最適化をそれほど求めないならv8_nosnapshot.libで十分だと思う。
Gitlab4.0へのアップデート部分的に成功
一箇所まだうまく行っていない場所はあるのだけれど、4.0へのバージョンアップが成功した。
失敗の原因は、Gitoliteのバージョンが、v2と古かったから。
下記のリンク先の方法で、v3へインストールし直すとバージョンアップは、完了できる。
Reinstall Gitolite
ただし
sudo -u git -H lib/support/rewrite-hooks.sh
で、シンボリックリンクを張る処理が、エラーになってしまう。
こちらについては、継続して調査中。
今回躓いたけれど、MySQLのデータベースとGitoliteのリポジトリ情報をバックアップすれば、サーバーの再構築もできるんじゃないかという情報が得られたのが収穫かな。
Gitlab3.1から4.0へのアップデート失敗
なんかバージョンが上がるたびに、アップデートのハードルが高くなっているような気がする。
今でも十分に満足してるんで、バージョンアップを諦めようかな・・・
おそらくクリーンインストールなら問題無いんですよ。
バージョン2の若い番号からバージョンアップを続けている環境だと問題が起きるのだと思う。
自宅の仮想環境で、3.1から4.0のバージョンアップには成功している。
クリーンインストールした環境に、データだけ移植するような手段は無いものだろうか。
公開モードが4.1から入る？
IssuesのMilestone: 4.1に、Add a public modeというのが、議論されています。
前々から要望が出ていた公開プロジェクトが、サポートされるかもしれません。
Add a public mode ( to be used with gitdaemon ) by crazyjul · Pull Request #2042 · gitlabhq/gitlabhq · GitHub
社内の共有ライブラリなどの置き場として、Gitlabを使用した場合には、ひどく使い勝手が悪かったので、大歓迎ですね。
どんな感じに実装されるのか楽しみです。
Gitlab 3.1へのバージョンアップも成功
GithubのIssuesでエラー内容を検索してみたところ開発者は、「もう、SQLiteはサポートしない」と言い切っておりMySQLへの移行は不可避な感じです。
個人的には、SQLite好きなのですが、移行を決断しました。
Wikiには、ちゃんとMySQLへの移行方法が説明されており、落ち着いて読めば難しい所は無いはずです。
GitHub - gitlabhq/gitlabhq: GitLab CE Mirror | Please open new issues in our issue tracker on GitLab.com
DBが大きいのか、マイグレーションには、少々時間がかかりました。
MySQLへの移行が済めば、3.1へのバージョンアップでつかえるところはありません。
次のバージョンは、4.0へのメジャーアップデートのようなので、3.1にアップデートできてよかった！
Gitlab 3.1のクリーンインストール成功
Virtualboxへ3.1のクリーンインストールが成功した。
MySQLのパスワード設定の作業が抜けていたみたい。SQLiteには無かった作業なので、ちゃんとコメント読めば書いてある。不覚。
これで、自宅でAPIを使った開発が進められる。
それに、バージョンアップの予行練習もできる環境が揃った。
あとは、会社の環境を無事にバージョン出来るかが勝負。
Gitlab 3.1へのアップデート失敗
ver3.1へのアップデートにあえなく失敗。
敗因は、SQLiteをMySQLへアップデートしていなかったからっぽい。
今回は、ブランチを切ってアップデートさせるなど設定ファイルもかなり変更されてるっぽいので、難しい。
仮想環境でクリーンインストールを試してみたけど、俺の腕だと途中エラーに・・・知識が足りなさすぎる。
