Koike MacOSX 2002/06/17

● 小池邦人のMac OS Xへの道　2002/06/17

～　Metrowerks CodeWarrior v8 到着す　～

今回はサンプルアプリケーションの話を一回お休みして、つい最近到着したMetrowerks CodeWarrior v8（英語版）の印象を書いてみます。

私は、仕事の開発環境としてはCodeWarriorの「英語版」の方を採用しています。その第一の理由は、バグフィックス用のパッチやアップデータが英語版の方が日本語版より数ヶ月先行して発表されるからです。開発環境のバグは、我々開発者にとって致命傷となりかねません。ですから、こうした問題点が解決されるまでの時間を短縮できることが、英語版を採用する大きなアドバンテージとなります。CodeWarrior v8は、Mac OS XのNative環境で起動できるようになってから3代目となります。バージョンを重ねるごとに安定してきている感があり、Mac OS X 10.1上での起動も高速で、エディタによるソースコードの編集も快適です。v7でよく遭遇した「コマンド＋Q」で終了しようとした時に「異常終了」するバグも、ちゃんと直っているようです（笑）。

今回のバージョンアップの「最大の売り」はCocoaベースのアプリケーションが開発できるようになった点でしょう。ひな形（テンプレート）プロジェクトを作成するための「New」ダイアログにも、「Mac OS X Cocoa Stationary」という項目が追加されています。

　

これを選択してプロジェクト名を入力し、続く「New Project」ダイアログで「Objective-C Application」を選ぶと、Cocoa Framework用のひな形プロジェクトが作成されます。残念ながら、私はCocoa Frameworkは利用しないので、「Mac OS C Stationary」を選択し、Mach-O版のCarbonアプリケーション用ひな形プロジェクトを作成してみました。ダイアログにプロジェクト名を入力しOKボタンをクリックしたら、続いて表示された「New Project」ダイアログのリスト項目から「Mac OS X Mach-O」->「Mac OS Toolbox」->「C Toolbox Mach-O Nib」を選びます。

　

出来上がったひな形プロジェクトの内容を見てみると、v7では見かけなかったファイルが追加登録されています。

　

「.plc」拡張子の付いたファイルは、パッケージに埋め込む「Info.plist」や「InfoPlist.strings」といったプロパティファイルの内容を記載したテキストです。

　

また、v8からは、リソースファイルだけではなく、Nibファイルもプロジェクトに登録することができるようになりました。このように、プロジェクトに登録しておいた「アプリケーションパッケージの部品」は、「Setting」ダイアログの「Project Type」を「Applicatiion Package」に設定することで、リンク時に自動的にパッケージ内に複製されます。

　

v7でアプリケーションパッケージを作成する時には、「Setting」ダイアログの数カ所で面倒なパス設定が必要でしたが、v8ではこうした煩雑な手続きをすることなく、アプリケーションパッケージが構築できるようになっています。これは使い勝手から言っても大きな進歩です。

当然、今まで同様にリソースファイルもプロジェクトに登録することができます。

　

何故だか、Nibファイルもリソースファイルも同じアイコンで表示されるのが少々分かり難いですね（笑）。プロジェクトからは、登録されているNibファイルをダブルクリックし、Interface Builderを起動することができます。その場合、Interface Builderの「Images」タブには、同じプロジェクトに登録されているリソースファイル内のアイコンやPICTリソースが表示されます。Project Builderのみで利用できていた機能が、CodeWarriorでも利用可能になったわけです。

　

ところが、私の開発環境で使っていたInterface Builde v2.2では、「Images」タブ内にリソース画像が表示されませんでした。これを「Developer Tools」の4月版に含まれている v2.2.1にアップデートしたら、うまく表示されるようになりました。この現象は私の環境だけかもしれませんが、もし表示されないようでしたら「Developer Tools」をアップデートしてみてください。最終的なプロジェクトフォルダの中身は、以下の様な状態となります。

　

プロジェクトファイル、ソースファイル、Nibファイル、アプリケーションパッケージが同階層に保存されています。雰囲気的には、Project Builderのプロジェクトフォルダの中身と同じです。

続いて、v7で開発をしてきた大規模なプロジェクトをv8に移行してみました。v8にはMetrowerks社オリジナルのLinker（リンカー）が搭載されています。「Setteing」ダイアログのLinkerを「Apple Mach-O PowerPC」から「Mac OS X PowerPC Mach-O」に切り替えます。

　

続いて、使用するPrefix File（プリコンパイルヘッダー）も「MacHeadersMacOSX」に変更します。

　

v7で使われていたApple社のLinkerは、何かと挙動不審な点がありました。例えば、浮動小数点の内部変数を整数に代入する処理を記述すると、リンク時に以下のようなエラーが表示されてアプリ構築に失敗する場合がありました。

　

何やら、数値変換用ルーチンがリンクできない雰囲気なのですが、この内部変数を外部変数に移動させると直ったりします（涙）。また、外部変数を大量に確保すると、処理がおかしくなるような現象にも遭遇しましたが、どちらもLinkerのバグだろうと推測されます。このような問題が発生していたv7のプロジェクトを、v8の新Linkerに通したところ、見事に問題は解消されていました。嬉しいかぎりです。

リンク速度ですが、ファイル数が100近い大規模なプロジェクトで試したところ、v7の「Apple Mach-O PowerPC」Linkerでは9秒かかっていた処理が、新しい「Mac OS X PowerPC Mach-O」Linkerでは5秒で完了しました。続いて、ファイルのコンパイルスピードを比較してみたところ、v7では1分18秒だったコンパイル時間が、v8では1分44秒かかりました。コンパイル処理が遅くなってしまったわけです。各種コンパイル設定は、v7からそのままv8のプロジェクトに引き継がれていますので、コードオプティマイズのレベルなどに変更は無いはずです。そこで、コンパイル後のオブジェクトコードの内容を調べてみると、v7と比べてv8は非常に容量が小さくなっていることがわかりました。左側がv7によるコンパイル結果で、右側がv8による結果です。

　

リンク後の実行ファイルの容量も、v7の388Kbyteと比較してv8は328Kbyteと随分小さくなっています。これは、このプロジェクト特有の結果なのでしょうか？みなさんの追試に期待したいと思います。

この結果が事実なら、v7のMach-O Nativeコード発生には随分と冗長な部分があったようです（最適化の手を抜いていた？機能のインプリメントが間に合わなかった？実行ファイルの構造が変わった？）。v8でのコンパイル時間は少々長くなりましたが、我々の日常作業を考えるとリンク時間の短縮の方が貢献します。また、ちゃんとシェイプアップされたMach-O Nativeコードが発生できるようになったのは大きな進歩ですね。これだけでも、v7からv8に切り替える意義はあるのではないでしょうか？

Metrowerks CodeWarrior v7からv8へのアップデートは、以下のウェブサイト経由で手続きすることができます。

http://cw.metrowerks.co.jp/metro/

新規パッケージを購入すると84,000円なのですが、アップデートに関しては30,000円ですみます。まだアップデートの手続きされていない方は、チャレンジされてみてはいかがでしょうか？英語が苦手で現状そんなに急がない方は、ちゃんとした日本語版が発表されるまで（夏の終わりか秋？）もう少し待つのも手です。それから、ウェブサイトからの注文の際には、間違えてWindows版を購入してないように注意いたしましょう！実は、私やってしまいました（笑）。まったくもって大ボケです（笑）。

● 小池邦人のMac OS Xへの道 2002/06/17

～ Metrowerks CodeWarrior v8 到着す ～

● 小池邦人のMac OS Xへの道　2002/06/17

～　Metrowerks CodeWarrior v8 到着す　～