とりあえず前回までの状況で、アプリケーションをBuildしてみることにします。Buildするには、プロジェクトウィンドウの左上にある「ハンマー」アイコンをクリックするか、もしくはBuildメニューから「Build」を選択します。
Buildはコンパイルとリンクを実行するだけですので、Buildが成功した時点でアプリケーションを起動したい場合には、Buildメニューの「Build and Run」を使うとよいでしょう。アイコンボタン側にも同じ機能は存在していないかと、shiftキーやoptionキーを押しながらBuildアイコンをクリックしてみましたが（笑）どうやら無いようです。アイコンボタンを使いRunさせる場合には、Build後に同じ並びの「モニター」アイコンをクリックしてください。Runの右隣がDebug用なのは理解できますが、その左隣の「ほうき？」アイコン（Buildメニューの「Clean」と同等）の役割が今ひとつ理解できません。クリックするとBuild済みのアプリケーションをハードディスクから削除するようですが、それだけの機能を提供するために彼はここに存在しているのでしょうか？謎であります。
さて、Buildをしてみると、コンパイルの途中でいくつもの細かなエラーが発生しました。利用していない自動変数が定義されているとか、プロトタイプ宣言が無いとか、現状のコンパイルのシンタックスチェックのレベルは、かなり高く設定されているようです。オプティマイズレベルやシンタックスチェックレベルに関する詳しい設定は、前回のリソース添付先の設定と同じく、プロジェクトウィンドウのTarget名のダブルクリックでオープンする情報設定ダイアログで行います。
情報ダイアログの「Built Settings」ダブの「Compiler Settings」でオプティマイズレベルを、「Expert Build Settings」でシンタックスレベルやその他の詳しいパラメータを設定することができるようです。しかし「Expert Build Settings」の方はダブルクリック後にテキスト入力すると言う太古のユーザインターフェースとなっており（涙）現状では使う気がしません。妙な設定でうまく動かなくなるのも嫌ですので、とりあえず現象のオプティマイズレベルやシンタックスチェックレベルに従い作業を進めることにします。
今回のリンクで最後まで残ったBuildの警告は（エラーでないのでBuildは成功する）、Carbon Print Manager APIのプロトタイプ宣言が無いという物でした。
これは、CarbonLib v1.2 SDKを使った場合でも起こる現象でして、Carbon Print ManagerのAPIが今までと同じ手法を使う物と、セッション（複数のプリントアウトを複数のプリンターに同時に行える仕組み）を使う物に分かれた事に起因します。どうも、ディフォルトではセッション用の方が定義されているようで、CarbonLib v1.2 SDKでも「#define PM_USE_SESSION_APIS 0」と定義しておかないと、非セッション用のCarbon Print Manger APIがリンクできません。ただ、実際にBuild後のアプリケーションを起動してみると、Printに関係する機能はちゃんと使えます。警告表示は出るのですがAPIへのリンクは問題ないようですので、今回は深く考えず、このまま作業を続けることにしました。
Buildする時は、リスト表示されているソースファイル名の左横の「小さな丸」が外れて（消えて）いないかチェックしてください。これが外れていると、そのソースはコンパイル対象外と判断されてリンク時にエラーが出ます。マウスクリックで簡単に外れますので、間違って外さないように注意しましょう。また、CodeWarriorでBuildを行うと、編集したソースファイルだけを対象にして再コンパイルを実行してくれます。ところが現状のProjectBuilderのBuildでは、リスト上の全ソースファイルを再コンパイルしてしまいます（涙）。編集したソースファイルがたった一つであってもでそうなるのです。この仕様（不具合？）は多分改善されると思いますが（ひょっとして現在でも切り替える設定があるのかも？）この状態のままだと、開発環境としては大きな欠点を持つことになってしまいます。
Buildが終了したら、出来上がった「ViewJPEG _X」をRunさせてみます。すると、なぜだかアプリケーションメニューが文字化けしていることに気づきました。
言語を「English」に切り替えてから新規の雛形プロジェクトをBuildしても、この現象は出るようです。よって、ProjectBuilderのバグだろうということで今回は無視しておきます。それ以外の機能は、CodeWarriorで作成したCFMベースのCarbonアプリケーションと何ら違いはありません。ところが色々と試しているうちに、起動スピードとアプリケーション容量が大きく違うことに気づきました。起動スピードは、CFMベースのViewJPEGよりもMach-Oベースの方が高速です。CFMベースのViewJPEGがDock内で4〜5回ジャンプしてから起動するのに対し、Mach-Oベースの方は2回ほどのジャンプで起動します。まあ、そうは言ってもCFMベースのViewJPEGの起動が遅くてイライラするというほどの長時間ではありません。それよりもビックリしたのは、アプリケーション容量の違いです。CFMベースのViewJPEGは、たった48Kバイトの容量しかありませんが、それと比較して同じソースコードから作成したMach-Oベースの方は、何と1.6Mバイト（メガですよ！）もあるのです。
何がそんなに容量を食っているのか調べるために、パッケージをほどいて中のファイルを調べたところ、やはりアプリケーション本体（起動コード部分）が容量の大部分を占めていました。考えられる原因は二つ。Mach-Oベースのランタイム環境（起動用ライブラリ）が大きいのか、利用したフレームワークがアプリケーション本体に実行コードまで追加しているのかどちらかです。QuickTime APIやCarbon Print Manager APIを使わないようにすると、アプリケーション容量が減っていきますので、原因は間違いなく後者のようです。Mac OS Xでの共有ライブラリの仕組みを構築している段階での暫定的な結果だと解釈しておきたいと思いますが、48Kバイトが1.6Mバイトになってしまうのは、いくら近年ハードディスクの容量が増大しているといっても少々困ったものです。Mac OS X完成時には改善されていることを期待したいと思います。
最後に、アプリケーションにジャイアントアイコンを付けてみます。アイコンファイルは、Developerフォルダ内のApplicationsフォルダにある「IconComposer」で作成します。IconComposerを起動し、適当なTIFFファイルをウィンドウ上へドラッグ＆ドロップして登録します。
ちなみに、128X128ピクセルのアイコンマスクはαチャンネルを利用しているようです。よって、先んじてPhotoShop等で対応した画像を作成しておく必要があります。今回はMac OS XのCD-ROMにあった適当なTIFFファイルを借用してみたところ、ちゃんと128X128アイコンにマスク処理がなされていました。これに「.icns」という拡張子を付けてファイルに保存した後に、プロジェクトリストの「Resources」グループに登録します。ところが、これだけではFinder上にジャイアントアイコンは表示されません、実際にはTragetの情報ダイアログをオープンし、その「Application Settings」タグに表示される「Icon File:」カラムにファイル名を入力する必要があります。
この時、アプリケーションの「Signature:」や「Document Types」も設定しておくと良いでしょう。
ところが、こうしたファイル情報を設定しても、何故だかアプリアイコン上へのドキュメントアイコン（JPEGファイル）のドラッグ＆ドロップでViewJPEG_Xが起動しません？果たしてProjefctBuilderでの設定や、リソースファイルとして付加したバンドルリソースは生きているのでしょうか？この開発環境（Finderの方か？）まだまだフィックスしなければならない問題が大量に残っているようです。
[小池邦人/オッティモ]