Japanino であれやこれや
結局 Japanino 付きの大人の科学を買ってしまう自分。おかしい。他に色々片付けてしまわなければいけないことが山積している筈なのに、か、体が勝手に....
とりあえず初期設定＆サンプルスケッチ実行こそ arduino IDE を使って動かしてみたものの、身に染み付いた Emacs 野郎魂＆ CUI 野郎魂がメラメラと燃え上がり、スケッチの build & upload を make コマンドで出来るようにすることに。っつーか、こういうところで変なスイッチが入ってしまうから、TODO リストが片付かないんだよなぁ .... orz
build & upload で IDE が何をやっているのかを知るには、preferences.txt ファイルに verbose 設定を記述すれば良いらしいとのことなのでやってみる。
うひゃー！ビルドの都度、ランタイムに必要なソースを全部コンパイルしなおしてる！
資源貧乏な 20 世紀では考えられない実現方式だけど、「事後インストールしたライブラリが上手く動かない云々」とかいうトラブルへの対応を考えるぐらいなら、富豪的解決策としては妥当なところか。
更に、実行手順を色々追跡してみると、スケッチ元となる .pde ファイルの冒頭に:
#include "WProgram.h" void setup(); void loop();
なんてコードを、コンパイラに渡す前に IDE が勝手に追加している模様。
ターゲット層(＝非プログラマ)を考えた場合、必須ヘッダファイルの読み込みや関数の事前宣言に関しては、「おまじない」なんて言い方でユーザに明示的にコードを記述させるよりは、このような「自動追加」というアプローチの方が確かにスマートな気がする。
もっとも、この手順をそのまま再現しようとすると、追加したコードの分だけコンパイルエラー時の行番号情報がアレしてしまうので:
- ソースファイル冒頭に、#include + 関数宣言を追加した別ファイルを生成
- 別ファイルに対してコンパイラを起動
- コンパイラの標準エラー出力を標準出力に振り替え
- ファイル名／行番号情報の書き換えによる補正
みたいなことをする必要が。
っつーか、20 世紀から手を染めている C プログラマとしては、コンパイラ様のご機嫌取りはお手の物なので、この辺の自動追加に関してはスッパリと実施しない方向で(笑)。
で、あれやこれや make と格闘すること暫し。ランタイムライブラリのコンパイルは、どうしてもソースファイルとオブジェクトファイルの場所が別になってしまうので、make 標準のサフィックスルールによる規則定義よりも、GNU make のパターンルールによる規則定義の方が妥当そうな感じ。
個人的には、標準 make 機能に限定することでの可搬性確保には拘りがあるのだけど、特殊なデバイスを扱うのに可搬性に拘ってもしょうがないので、GNU make 限定としてしまおう。心配なのは標準の Solaris 環境で arduino したくなった時ぐらいか？(笑)
build までは上手く行く様になったので、upload に関しても IDE の内幕を覗いて見る事に ..... げ！ verify 後に upload すると、またランタイムのビルドからやり直してる！そりゃ、upload に時間が掛かるはずだ .... orz
うーむ、富豪的プログラミングにも程がある(笑) > arduino IDE
upload の処理そのものは単純なコマンド起動なので、make 化はさっくり完了。
ランタイムライブラリ群のビルドや、upload 前のスケッチのビルドは、ソース改変が無ければ一度しか実行されないので、スケッチ修正〜再実行に要するサイクルが大幅に短縮されたのは大きいなぁ > make 化
追加ライブラリの使用に関しても、ライブラリ毎の設定ファイルを Makefile で include すれば良いように頑張ってみたので、結構使い勝手が良いものが出来た気がする。
なんか頑張り所を間違えている気もするが、自分としては満足なので良しとしよう(笑)。
