アップルは先日、インテル製マイクロプロセッサへの移行計画を発表しました。これが公開されたときには、直ちに皆さんのアプリケーションもインテルベースのMacintoshコンピュータでネイティブに実行するように、今から準備しておく必要があります。ただし、PowerPC Mac上でアプリケーションを実行し続ける必要もあります。おそらく、移行を完了させるために必要な作業量が気になることでしょう。 アプリケーションの移行にかかる作業量は、使用するコードの種類と現在使用しているコンパイラによります。下記の移行計画図に、最も一般的な3つの移行パス（Transition Path）を示します。全面的にJava、Applescript、その他アーキテクチャに依存しない言語で書かれたコードからなるプロジェクトであれば、作業は必要ありません（C、C++、またはObjective-Cを混ぜている場合は注意が必要です）。他の2つのパスでは、Universal Binaryを作成する必要があります。PowerPCコンピュータとインテルベースのMacintoshコンピュータでネイティブに実行するアプリケーション、ライブラリ、およびフレームワークです。バイナリを作成するためのユニバーサルなオプションは、簡単に設定できます。コードをその状態にするまでが、必要な作業のほとんどを占めています。 
以降のセクションでは、各パスに必要な作業について説明するとともに、役立つ参考資料も紹介します。採用する移行パスに関係なく、ビルドするアプリケーションがある場合は、それを両方のアーキテクチャでテストする必要があります。Developer Transition Kitを入手するか、CupertinoのADC Compatibility Labsを利用するよう手配する必要があります。
移行パスへ進む前にコードの準備またはコンパイルの前に、PowerPCベースのMacintoshコンピュータ向けに開発されたアプリケーションを、インテルベースのMacintoshコンピュータで実行するのを妨げる可能性のある主要な問題を理解しておく必要があります。Java開発者の方や、アーキテクチャに依存しない別の言語を使用している方であっても、問題を理解しておくと役に立ちます。 『Universal Binaryプログラミングガイド』の以下のセクションを参照してください。 - 「はじめに」では、移行を開始するための前提条件を示しています。
- 「アーキテクチャ面での相違」は、移植可能なコードを理解して書くうえで役立ちます。
- 「バイトのスワップ」では、最も根本的な違い、すなわちバイト順序についての詳細と、それに対処する方法を述べています。必要なコード変更のほとんどは、アーキテクチャ間でのバイト順序の違いから生じるため、この章を注意深く読む必要があります。
同じドキュメントの「シナリオ別のガイドライン」にはざっと目を通してください。そこで説明されている状況のほとんどは、皆さんのアプリケーションには該当しませんが、何がコードに影響する可能性があるかを見る価値はあります。後のデバッグ時間を大幅に短縮できるかもしれません。
AltiVecコードを使用するMac OS XプロジェクトAltiVecコードは、PowerPCアーキテクチャ固有のコードです。次のいずれかの方針をとる必要があります。 - AltiVecコードをAccelerateフレームワークに置き換える。オペレーティングシステムがチップ固有の最適化を実行してくれるので、この方法のほうが好まれます。Mac OS Xを実行する特定のハードウェアについて気にする必要がありません。
- インテルベースのMacintoshコンピュータ向けに、アーキテクチャ固有のコードを記述します。このアプローチは、Accelerateでは行うことができない最適化処理が必要な場合に限り推奨されます。
『Universal Binaryプログラミングガイド』の「ベクトルベースコードの準備」を参照してください。
コンパイルにCodeWarriorを使用するMac OS XプロジェクトCodeWarriorからXcode 2.1以降にプロジェクトを移行する必要があります。『XcodeへのCodeWarriorプロジェクトの移植に関する概論』を参照してください。 プロジェクトをXcode 2.1以降に移行したら、次のドキュメントを参照し、該当する設定についての情報を見つけてUniversal Binaryを作成します。 プロジェクトでPowerPlantフレームワークも使用している場合は、『Universal Binaryプログラミングガイド』のPowerPlantについてのセクションを参照してください。
コンパイルにXcodeを使用するMac OS XプロジェクトプロジェクトがXcode 2.0以前を使用している場合は、これをXcode 2.1以降に移行する必要があります。Xcode 2.1から、コンパイラはGCC 4.0になっています。直面する問題のほとんどは、そのコンパイラの使用に関するものになるでしょう。『Porting to GCC 4.0 Release Notes』を参照してください。 Xcode 2.1以降を使用して正常にプロジェクトをコンパイルできたら、次のドキュメントを参照し、該当する設定についての情報を見つけてUniversal Binaryを作成します。 プロジェクトでPowerPlantフレームワークも使用している場合は、『Universal Binaryプログラミングガイド』のPowerPlantについてのセクションを参照してください。
コンパイルにmakefileを使用するオープンソースプロジェクトおよびUNIXプロジェクトmakefileを使用してビルドされるアプリケーションは、GCC 4.0以降を使用してコンパイルする必要があります。 バージョン4.0よりも前のGCCを使用している場合は、GCC 4.0に切り換える必要があります。『Porting to GCC 4.0 Release Notes』を参照してください。 GCC 4.0以降を使用している場合は、適切なクロスアーキテクチャの設定を行ってUniversal Binaryを作成します。次に示す参考資料から、クロスアーキテクチャの設定についての情報を見つけることができます。また、Universal Binaryをビルドする際のGNU Autoconfマクロの使用に関する問題についても解説されています。
Java、AppleScript、Python、JavaScript、シェルスクリプト、その他アーキテクチャに依存しない言語 アーキテクチャに依存しない言語を使用しているコードはプリコンパイルされません。つまり、注意すべきことは1つだけで、作業は完了するということです。JavaアプリケーションがJNIライブラリを使用している場合は、ライブラリにJava以外のコード(C、C++、Objective-C)が含まれているので、これらのライブラリをユニバーサルにビルドする必要があります。
テストとデバッグユニバーサルな、つまりPowerPC MacかインテルベースのMacintoshかに依存しない設定でアプリケーションをビルドしても、それで移行が完了するわけではありません。アプリケーションが動作するはずのすべてのシステム上で、テストを実行することが重要です。さらに、インテルベースのMacintosh上でアプリケーションをテストする場合には、期待通りでなければならない動作がいくつかあります。予期しない数値結果、間違った色などの動作は、アーキテクチャ間でのバイト順序の違いや、その他の違いからくる症状です。詳細については、『Universal Binaryプログラミングガイド』の「トラブルシューティング」のセクションを参照してください。
その他の参考情報アップルは、移行作業を最初から最後まで支援するために次の参考情報を提供しています。
|
