eclipseをネイティブで [Raspberry Pi]
実は今、僕は会社の設備にRaspberry Piを使っていこうと考えている。それには幾つかの理由があるんだけど、そのためにRaspberry PiにもXcodeのようなIDEが欲しい。やはりいつまでもviで書いてmakeを実行して、というのでもあるまいし、それではOS XにXcodeでひょいひょいと書くのにくらべて開発効率はどうしても落ちてしまう。いや、もちろん20年前はviとmakeで仕事していた。でも前にも書いたけど、その当時に比べてRaspberry Pi 2はクロックは一桁、メモリは二桁増えている(もちろん十進で)。なにかいい手はないか。
ところがまあ、あたりまえだけど、そのクロスのコンパイラはlinux用にビルドされていて、OS Xでは動かない。それにコンパイラがARMのコードを吐けるというだけではまだ足りなくて、Cのランタイムをはじめとしてたくさんあるライブラリが整合的にリンクできないといけない。OS Xとlinuxとではライブラリの形式も違っているので、リンクシステム全体をポートしないといけない(つまりXcodeで言えばiOSのsdkと同じものを作らないといけない)。その点、Raspberry Pi側がRasbianでホストがlinuxであればリンク形式の問題は敷居が下がる(といっても「いけいけ」になるわけではない)。
ある人はVirtualBoxの上でubuntuを走らせて、そこにeclipseとクロスコンパイラを持ってきて動かしている。曲芸のようだけどちゃんと動いてソースデバグもリモートでできるらしい。これはすごい。
でもやっぱり、環境の構築にはかなりの苦労が必要で、ホスト側のメモリも大量に消費することになる。もう少し違う方法はないか。
Raspberry Pi 2ならメモリは倍に増えているし、4コア持っている。ましになっているかもしれない。と思って挑戦することにした。 以前やったのはもう完全に忘れてしまってるので、同じ苦労を繰り返すことになってしまった。
まずeclipseをインストールした。僕はjavaを使わなくてC/C++がコンパイルできればいい。そこで
結局、なぜかjdkを8に入れ替えるとeclipseが動いた。確認したところ古い方のRaspberry Piはjdk6で動いている。古いほうは完全に立ち上がったところまで確認したわけではないので、バージョンの問題ではないとは言い切れない。こういうのってほんとに混乱する。また、とりあえず動くんだけどstderrに大量のwarningが出力される。ほとんどがGObjectのwarningで、ときどきjavaのが含まれている。eclipse自身は動いているみたいなんだけど、意味のよくわからないwarningが大量に出るのは精神衛生上あまりよろしくない。でもどうすればなくなるのか、あるいはほっといてもいいのか見当もつかない。
でもとりあえずスプラッシュが出て、workspaceを選択するダイアログが表示された。javaのVMはコアひとつを占領するだけで、シングルコアと同じだけど、前とは明らかに違ってスラッシングするほどではなさそうである。メモリが増えたのが良かったんだろう。makeは4コアを有効に使えるので、コンパイル時間に対しては期待できるはずだけど、それはIDEにしなくても同じで、結局eclipseの動作はシングルコアの性能(と仮想記憶の性能)だけが効くことになる。
OS X側で
そしてRaspberry Pi 2側で
こうするとネイティブのeclipseなのでクロス環境の構築はもちろん必要ないし、ライブラリを追加したりバージョンを更新したりということに気を使う必要はない。当然クロスよりもずっと遅いけど、役に立たないほどではない。エディタへのキー入力は快適、とは言えないにしてもいちおう問題なくついてくる。
たとえばプロジェクトをひとつ作って、いつも最初に書く
7つのCのソースファイルを含んだ30kBほどの小さなプロジェクトをビルドすると2秒ほどで終わるので、例えばコンパイラをビルドするというような、かなり大きなプロジェクトでなければ十分使い物になるのではないかと思う。
しかし、eclipseの起動にはかなり時間がかかる。スプラッシュスクリーンが表示されるまでにたっぷり1分、workspaceを指定するダイアログのOKボタンを押してからウィンドウが表示されるまでにさらに1分かかる(その間忙しくしているのはjavaのVMが走っている1コアだけ、というのが残念。これはjavaだからというのではなく、eclipseがそう書かれているからだけど)。workspaceを切り替えるだけでもどうやら起動プロセスを繰り返すらしくて、同じだけの時間がかかる。
それと、残念ながらショートカットはコマンドキーではなくコントロールキーを使うWindowsライクなキーコンビになる。VirtualBoxでlinuxを動かしたとしてもそこは変わらないのでこれはまあしょうがない。
例えば、eclipse本体をホストで動かして、makeをリモートのRaspberry Pi上で実行する(ファイルシステムはリモート側を使うことになるんだろうな)、なんていうことができたら、ホストの慣れ親しんだUIで、クロスよりかはずっと遅いけど、ライブラリやヘッダファイルの整合性を気にする必要はなく、しかもeclipseごとリモートで動かすより軽い、ということで僕にはちょうどいい。そんなことができるかというと、できそうな気はするけどそこまで突っ込むにはeclipseをよく理解していないとできない。誰か詳しい人がやってくれないかな。
とりあえず今の状態でも、eclipseが立ち上がればそれなりに使えるので、使えるだけマシ、と思うけど、起動に2分なんて聞くと、最近の人は文句を言うんだろうなあ。
0.0.1 クロス環境
クロスプラットフォームな開発環境としてProjectBuilder/Xcodeパクリ(と書くとその筋から顰蹙を買うけど、僕は機能性能よりもオリジナリティを評価するという立場をとっているので。それを言ったらCodeWarriorパクリのMPWパクリというバックトラック連鎖に陥るな)のeclipseがあってRaspbian(Raspberry Pi専用linux)上にも移植されているが、多くの人はRaspberry Pi 2が出る前はeclipseをネイティブに動かすのを最初から諦めていて、クロス環境を構築していた。クロスのコンパイラを作ってくれた人がいて、それとeclipseを組み合わせて使っている人がいる。なかなかeclipseをよく知っていないとできないことで、かなり深い。ところがまあ、あたりまえだけど、そのクロスのコンパイラはlinux用にビルドされていて、OS Xでは動かない。それにコンパイラがARMのコードを吐けるというだけではまだ足りなくて、Cのランタイムをはじめとしてたくさんあるライブラリが整合的にリンクできないといけない。OS Xとlinuxとではライブラリの形式も違っているので、リンクシステム全体をポートしないといけない(つまりXcodeで言えばiOSのsdkと同じものを作らないといけない)。その点、Raspberry Pi側がRasbianでホストがlinuxであればリンク形式の問題は敷居が下がる(といっても「いけいけ」になるわけではない)。
ある人はVirtualBoxの上でubuntuを走らせて、そこにeclipseとクロスコンパイラを持ってきて動かしている。曲芸のようだけどちゃんと動いてソースデバグもリモートでできるらしい。これはすごい。
でもやっぱり、環境の構築にはかなりの苦労が必要で、ホスト側のメモリも大量に消費することになる。もう少し違う方法はないか。
0.0.2 ネイティブのeclipse
ずっと昔、Raspberry Pi 2を手に入れる前に、Raspberry Pi Model Bでeclipseを立ち上げようとした。eclipseのスプラッシュスクリーンが表示されたまま10分たっても変化がない。完全にスラッシングを起こしているらしく、あきらめた。やっぱりjavaだもんな。Raspberry Pi 2ならメモリは倍に増えているし、4コア持っている。ましになっているかもしれない。と思って挑戦することにした。 以前やったのはもう完全に忘れてしまってるので、同じ苦労を繰り返すことになってしまった。
まずeclipseをインストールした。僕はjavaを使わなくてC/C++がコンパイルできればいい。そこで
raspi2:~> sudo apt-get install eclipse-cdtで、C/C++環境をインストールした。ところが動かない。コアダンプを吐こうとして大きすぎてできない、logを残す、というメッセージを出して終了する。そのlogを見てもよくわからない。javaのリンクエラーが致命的だったようである。その他にもgtk+のメッセージやらGObjectのwarningがあってどれが引き金になっているのかわからない。
結局、なぜかjdkを8に入れ替えるとeclipseが動いた。確認したところ古い方のRaspberry Piはjdk6で動いている。古いほうは完全に立ち上がったところまで確認したわけではないので、バージョンの問題ではないとは言い切れない。こういうのってほんとに混乱する。また、とりあえず動くんだけどstderrに大量のwarningが出力される。ほとんどがGObjectのwarningで、ときどきjavaのが含まれている。eclipse自身は動いているみたいなんだけど、意味のよくわからないwarningが大量に出るのは精神衛生上あまりよろしくない。でもどうすればなくなるのか、あるいはほっといてもいいのか見当もつかない。
でもとりあえずスプラッシュが出て、workspaceを選択するダイアログが表示された。javaのVMはコアひとつを占領するだけで、シングルコアと同じだけど、前とは明らかに違ってスラッシングするほどではなさそうである。メモリが増えたのが良かったんだろう。makeは4コアを有効に使えるので、コンパイル時間に対しては期待できるはずだけど、それはIDEにしなくても同じで、結局eclipseの動作はシングルコアの性能(と仮想記憶の性能)だけが効くことになる。
0.0.3 OS X側でのX-Serverを使う
こうなるとなるべくRaspberry Pi 2側はよけいなことをさせないで、実メモリをjavaのVMに回すほうがいい。そこで前もやったけど、OS X側でX-Windowのサーバを動かして、eclipseはリモートのXクライアントとして動かそう。VNCだと、Xクライアントだけでなく、X-ServerとVNCの通信処理(Xのプロトコルよりずっと重い)がRaspberry Pi 2上で走ることになるが、それをやめることができる。OS X側で
[iMac:~] % setenv DISPLAY iMac.local:0.0 [iMac:~] % /usr/X11/bin/Xquartz & [1] 6067 [iMac:~] % /usr/X11/bin/quartz-wm & [2] 6077 [iMac:~] % xhost +raspi2.local raspi2.local being added to access control list [iMac:~] %としてXQuartz(OS X用のX11サーバ)を走らせておく。iMacというのはホストにしたOS Xのマシンの名前である。ちなみに僕はcshしか使えないので、デフォルトのbashその他を使っている人は読み替えてほしい。また、X11サーバを起動する前はデフォルトではX11のbinディレクトリにはパスは通っていない。
そしてRaspberry Pi 2側で
raspi2:~> setenv DISPLAY iMac.local:0.0 raspi2:~> eclipseとやると、XQuartzのウィンドウとしてeclipseが立ち上がった。Zeroconfは便利。 こんな感じ。 ちなみにRaspberry Pi側でZeroconfに応答するにはavahiをインストールしておけばいい。
raspi2:~> sudo apt-get install avahi-daemonZerconfを走らせておけばDNSがないローカルな(192.168.x.xみたいな)環境でもIPアドレスを調べることなく名前で解決できる。
こうするとネイティブのeclipseなのでクロス環境の構築はもちろん必要ないし、ライブラリを追加したりバージョンを更新したりということに気を使う必要はない。当然クロスよりもずっと遅いけど、役に立たないほどではない。エディタへのキー入力は快適、とは言えないにしてもいちおう問題なくついてくる。
たとえばプロジェクトをひとつ作って、いつも最初に書く
#include <stdio.h> int main(int argc, char *argv[]) { printf("hello\n"); return 0; }をコンパイルすると、
09:17:41 Build Finished (took 214ms)で、どうしようもなく遅い、というほどではない。
7つのCのソースファイルを含んだ30kBほどの小さなプロジェクトをビルドすると2秒ほどで終わるので、例えばコンパイラをビルドするというような、かなり大きなプロジェクトでなければ十分使い物になるのではないかと思う。
しかし、eclipseの起動にはかなり時間がかかる。スプラッシュスクリーンが表示されるまでにたっぷり1分、workspaceを指定するダイアログのOKボタンを押してからウィンドウが表示されるまでにさらに1分かかる(その間忙しくしているのはjavaのVMが走っている1コアだけ、というのが残念。これはjavaだからというのではなく、eclipseがそう書かれているからだけど)。workspaceを切り替えるだけでもどうやら起動プロセスを繰り返すらしくて、同じだけの時間がかかる。
それと、残念ながらショートカットはコマンドキーではなくコントロールキーを使うWindowsライクなキーコンビになる。VirtualBoxでlinuxを動かしたとしてもそこは変わらないのでこれはまあしょうがない。
例えば、eclipse本体をホストで動かして、makeをリモートのRaspberry Pi上で実行する(ファイルシステムはリモート側を使うことになるんだろうな)、なんていうことができたら、ホストの慣れ親しんだUIで、クロスよりかはずっと遅いけど、ライブラリやヘッダファイルの整合性を気にする必要はなく、しかもeclipseごとリモートで動かすより軽い、ということで僕にはちょうどいい。そんなことができるかというと、できそうな気はするけどそこまで突っ込むにはeclipseをよく理解していないとできない。誰か詳しい人がやってくれないかな。
とりあえず今の状態でも、eclipseが立ち上がればそれなりに使えるので、使えるだけマシ、と思うけど、起動に2分なんて聞くと、最近の人は文句を言うんだろうなあ。
2015-08-18 21:47
nice!(0)
コメント(0)
トラックバック(0)
コメント 0