目次


XPCOM: 第 3 回: XPCOM のセットアップ

XPCOM 開発環境の構築

Comments

XPCOM を使うアプリケーションや、XPCOM コンポーネント自身の実際の作成作業に入る前に、適切な開発環境が必要になります。すべてのツールが適切な場所に存在し、正常に機能していることを確認する最良の方法は、Mozilla ブラウザーを作成してみることです。

lizard の作成

Mozilla は "the lizard" としても知られていますが、XPCOM と XPConnect の上に作成されるため、これを作成することは、ライブラリーと一群の有用な XPCOM コンポーネントを手に入れることに相当します。そのうちのいくつかは、ブラウザーと共存させなくても構わないものです。www.mozilla.org にアクセスし、ソース・コードと補足的な開発ツールをダウンロードし、全体をビルドしてください。Mozilla コードでは、ビルドするときに、コンパイラー固有のプロジェクト・ファイルではなく、汎用の make ファイル、シェル・スクリプト、および Perl スクリプトを使います。この「最小公分母」的なアプローチは、異なるプラットフォーム上でも同じ方法で同じコードを確実にビルドできるようにする唯一の方法です。

このアプローチでは、大量のディスク・スペースを消費するので注意してください。これを執筆している時点で、ソース・コードの tar ファイルを解凍するだけで、28567 ものファイルが出現し、160,975,003 バイトを消費します。NTFS ではファイル・システムが効率的ではないため、この作業に 244,293,632 バイトもの実ディスク・スペースが使われます。ソース・コードだけ でこのような状態です!リリース・ビルド後のソース・コードとバイナリー・ファイルになると、450 メガバイトに届くかというところでしょう。しかもここには、他のツールのためのディスク・スペースや、デバッグ・ビルド作成のためのスペースが含まれていないのです。

CVS

異なるプラットフォームで同じソース・コードをコンパイルできるマジックを実現できる理由の 1 つは、非常に多くのプラットフォームへ移植されているいくつかのツールに可用性があることです。そのようなツールには、gmake、CVS、および infozip 等があります。

CVS -- Concurrent Versioning System はシンプルですが、よく使われていてテストを重ねられた、マルチユーザーのソース制御およびバージョン付けシステムです。これを使うことにより、たくさんのプログラマーが大規模なプロジェクトで協調できます。機能的には、Microsoft 社の SourceSafe ツールと比較できます。RCS は、同様な別の UNIX 専用プログラムです。

CVS は、バグやパッチを追跡するためのツールで、いわば Mozilla の兵器庫に蓄えられているえり抜きの武器といえます。CVS を使うときにもっとも興味深い点は、ソース・コードに対する変更が皆に適用できるようになったら、すぐに最新の変更を増分的にダウンロードしてソース・コードに適用する機能でしょう。次の tar ファイルのリリースを待つことをいとわないのであれば、CVS についてはスキップしても構いません。

CVS サーバーではパスワードが必要です。モジュール所有者としての信頼性を得て、書き込みアクセス権限を持つユーザーとして指名されたのでない限り、汎用の読み取り専用アカウントを使うことになります。ただし、何も貢献することができないということではまったくありません。その場合は、直接モジュール所有者に対してパッチをサブミットして検討してもらうことになります。

Windows 環境のセットアップ

ここでは、MS Windows についてのステップをさっとたどります。

  1. 最新のアップデート (筆者が確認した時点では Service Pack 4 まであります) すべてを含めて、Microsoft Visual C++ 6 がインストールされていることを確認します。gcc のような Windows 上の他のコンパイラーをサポートする取り組みが進行中ですが、今のところ、VC6 だけが動作確認されています。SP3 を含む VC5 も動作することになっていますが、私は確認していません。
  2. コンパイラー、リンカー、および make ツールをシェル・ウィンドウから実行できることを確認します。
    • "cl" と入力します - "Microsoft (R) 32 bit Optimizing C/C++ compiler version .." のような表示が出ます。
    • "nmake" と入力します - "Microsoft (R) Program Maintenance Utility ..." のような表示が出ます。
    • "lib" と入力します - "Microsoft (R) Library Manager ..." のような表示が出ます。

      いずれも動作しない場合、後述のステップ 5 に示されている環境変数のヒントを参照してください。

  3. ソース tar ファイルをダウンロードし (参考文献を参照)、空き容量がたくさんあるディスク (最小で約 1 ギガ、同時にデバッグとリリースの両方のビルドをする場合は 2 ギガ) の "mozilla" ディレクトリーに内容を unzip します。
  4. cygwin、Active State Perl、および infozip のような、必要とする補足ツールをダウンロードします (これらのプログラムへのリンクは、参考文献を参照してください)。tar ファイルを unzip するときに、winzip や pkzip を使えますが、Mozilla の make ファイルでは、作成の一部として infozip を使います。
  5. 次の環境変数を定義する必要があります:
    Windows 9X の場合、次のように 2、3 のコマンドを AUTOEXEC.BAT に追加します:
     set PATH=%PATH%;C:\cygwin\bin;C:\progra~1\micros~1\common\msdev98\bin;c:\perl\bin
     C:\progra~1\micros~1\vc98\bin\vcvars32
     set MOZ_BITS=32
     set MOZ_SRC=C:
     set MOZ_TOOLS=C:
     set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot

    Windows 2000 の場合、[コントロール パネル] にナビゲートし ([スタート/設定/コントロール パネル] の順にクリックします)、[システム] をクリックして、[詳細] タブを選択し、[環境変数] をクリックして、編集ダイアログを表示します。それぞれのシステムで、次に示す設定またはそれに相当する同様の設定事項 (表 1 を参照) を調べます。

表 1. システム環境変数
PATHC:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;
C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin;
C:\Program Files\Microsoft Visual Studio\Common\Tools;
C:\Program Files\Microsoft Visual Studio\VC98\bin;
C:\Perl\bin;
C:\cygwin\bin
includeC:\Program Files\Microsoft Visual Studio\VC98\atl\include;
C:\Program Files\Microsoft Visual Studio\VC98\mfc\include;
C:\Program Files\Microsoft Visual Studio\VC98\include
libC:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;
C:\Program Files\Microsoft Visual Studio\VC98\lib
MSDevDirC:\Program Files\Microsoft Visual Studio\Common\MSDev98
MOZ_BITS32
MOZ_SRCC:
MOZ_TOOLSC:
CVSROOT:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot

正確な PATH の指定先は、ツールをインストールした場所に応じて異なります。MOZ_SRC 変数は、mozilla ディレクトリー・ツリーのすぐ上 のディレクトリーを指していなければなりません。MOZ_TOOLS 変数は、cygwin ツールの bin ディレクトリーのすぐ上 のディレクトリーを指している必要があります。

Cygwin GNU ツール

インストールするサード・パーティー・ツール群の最初のものは、Windows 用に移植された GNU コマンド行ツール群です。ファイル "setup.exe" をダウンロードして実行します (この作業をするために、アクティブなインターネット接続が必要です)。セットアップ・プログラムは、選択したコンポーネントをダウンロードしてインストールします。必要なコンポーネントは、ash、cygwin、diff、fileutils、gawk、grep、sed、shellutils、textutils、unzip、およびzip です。このような GNU ツールをダウンロードするときに、Perl および CVS を取ってくることもできますが、そうはしないでください。ビルドのエキスパートは、他の場所で入手できる異なるバージョンをお奨めしています。別のモジュールをダウンロードするといくらか時間がかかりますので、少し我慢してください。

Infozip

ビルド・プロセスには、JAR ファイルを作成するための infozip が必要です。上記の cygwin セットアップには、zip およびunzip (infozip の 2 つの部分) を、ダウンロードしてインストールするためのオプションがあります。infozip ツールを入手する別のルートとして、次のステップを行うことができます。zip ツール配布物は ZIP ファイルで配布されるため、それを unzip するために、別の unzip が必要になります。infozip のサイト (またはいずれかのミラー・サイト) から、ファイル "unz542xN.exe" および "zip23xN.zip" を、一時ディレクトリーへダウンロードし、次のコマンドを入力します:

cd \temp
unz542xN
unzip zip23.zip
copy *.exe c:\bin

Netscape Wintools

Netscape は、たくさんの GNU コマンド行ツールを修正し、いくつかの問題を解決しています。そのほとんどは、GNU スタイルの UNIX ビルドとの間の make ファイルの互換性の問題です。このバンドルのインストーラーは、MOZ_TOOLS 変数を使って、いくつかの実行可能ファイルのインストール先を判別するため、前述の環境変数を追加しておく必要があります。次のコマンドをコマンド・プロンプトから実行すると、wintools.zip ファイルがデフォルトのディレクトリー "buildtools" に unzip され、インストールが完了します。

cd \temp
unzip wintools.zip
cd \buildtools\windows
install

上記のステップでは、実際に "C:\bin" および "C:\include" ディレクトリーが作成されます (ただし、MOZ_TOOLS が "C:" にあると定義したとして)。スペースを節約しようと思えば、このステップの後に "buildtools" の下にあるすべてのものを削除できます。他のツールとは違って、Netscape Wintools へのパスは、PATH 環境変数内に含めない ようにします。make ファイルでは、gmake および Netscape によって修正された他のバイナリーを見つけるため、MOZ_TOOLS を使います。

Perl

Active State Perl をインストールすることは、恐ろしく簡単です。Windows Installer モジュール、つまり MSI ファイルとしてダウンロードするだけでよいのです。Windows のエクスプローラを使い、Perl をダウンロードしたフォルダーを参照し、"ActivePerl-5_6_0_616-MSWin32-x86-multi-thread.msi" のようなファイルをクリックします。

小さなことですが、2 つの「要点」にお気づきでしょうか。まず、インストーラーは "\Perl\bin" を PATH 環境変数へ追加します。Windows NT か Windows 2000 を実行している場合、このことは現在ログインしているユーザーにのみ適用されます。次に、Windows 9X か NT を実行している場合、Microsoft 社の Web サイトから、Microsoft Windows Installer パッケージをダウンロードしなければならない場合があります。

最後のテストとして、マシンをリブートして変更を有効にします。コマンド行ウィンドウを開き、コマンド・プロンプトにサード・パーティー・ツールの名前を入力し、それぞれのツールを実行してみます。実行してみるとよいコマンドは、ash、diff、grep、perl、およびunzip です。

ここまでのステップは、ビルド環境を作成するときまたは再作成する場合にのみ必要なものです。ここからのステップは、実際に Mozilla をビルドするたびに実行する必要のあるものです。

デバッグ・ビルドを実行する場合、ビルドの直前に次のコマンドを入力します:

set MOZ_DEBUG=1

知っておくと役立つその他のオプションは、次のようなものがあります:

  • SVG サポートを追加する MOZ_SVG
  • MathML サポートを追加する MOZ_MATHML
  • LDAP サポート用の MOZ_LDAP_XPCOM
  • ビルドのときに zip の使用で混乱したくない場合に役立つ MOZ_DISABLE_JAR_PACKAGING
  • その他に、試してみる価値がある MOZ_LITE、MOZ_MEDIUM、および MOZ_MAIL_NEWS

最後に、次のコマンドを実行してビルドを開始します:

nmake /f client.mak build_all

この時点で発生する可能性のある一般的なエラーのほとんどには、失敗になるコマンドを発行する make ファイルが関係しています。失敗の理由としては、コマンドに指定したツールがないか、検索パスに示されていないかのいずれかです。ビルド環境の間違いが解消されれば、ビルド・プロセスが 2、3 時間かけて実行されます (うそではありません)。

正しい作成環境であったとしても、実行して問題が生じる場合もあります。上記の手順が妥当かどうかを調べるために、mozilla-0.7 tar ファイルでテストしてみました。PR_CLIENT_BUILD_WINDOWS オプションをセットすると、NSPR モジュールで gmake がクラッシュするという問題がすぐに発生しました (NSPR は、一番最初にビルドされるモジュールです)。mozilla-0.8 tar ファイルをダウンロードして unzip し、上記のコマンドを再実行したら、コンパイルはすべてうまくゆきました。Mozilla ビルド・ページ (参考文献を参照) には、一般的なエラーとその解決方法のリストが示されています。

Windows での CVS

cvshome.org のサイトから、Windows 用の CVS バイナリーをダウンロードします。

次に示すのは、CVS サーバーからソース・ツリー全体を引き出すためのコマンド・シーケンスです:

  • set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
  • set HOME=\TEMP
  • cvs login (CVS ログインのプロンプトに応答)
  • cvs checkout mozilla/client.mak
  • cd mozilla
  • nmake -f client.mak pull_all

次に示すのは、変更したファイルだけを CVS サーバーに送達させることで、(最新の tar ファイルのように) 既存のソース・ツリーを更新するコマンド・シーケンスです:

  • set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
  • set HOME=\TEMP
  • cvs login (CVS ログインのプロンプトに応答)
  • cd mozilla
  • cvs -z3 checkout -PA mozilla/client.mk
  • nmake -f mozilla/client.mak checkout MOZ_CO_FLAGS=-PA

Linux 環境のセットアップ

Windows のときとは対照的に、プログラマー・フレンドリーなほとんどの Linux 配布版には、Mozilla を作成するのに必要なすべてのツールがそろっています。Debian や RedHat や Slackware などの Linux CD を入手したら、ありがたいことに、必要な部品がすべてそこに入っているわけです。ビルド環境を整えて実行するために必要な点は、どのバージョンがインストールされているかを確認することだけです。

次に、必要なパッケージのまとめを示します:

  • C++ コンパイラー
    • egcs
    • gcc
  • GNU make
  • GTK/GLib
  • Perl 5
  • zip

環境変数を次のように設定します:

  • ・setenv MOZ_BITS 32
  • ・setenv MOZ_SRC=/usr/home
  • ・setenv CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot

次のようにして mozilla ディレクトリーから config ツールを実行します:

cd mozilla./configure

mozilla ディレクトリーから、デフォルトのビルドを実行します:

gmake

mozilla ディレクトリーから、手動のビルドを実行します:

gmake -f client.mk build

Linux での CVS

次のコマンドを使い、CVS からソース・ツリー全体を引き出します:

  • setenv CVSROOT :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
  • cvs login (CVS サーバー・ログインのプロンプトに応答)
  • cvs checkout mozilla/client.mk
  • cd mozilla
  • make -f client.mk checkout

次のコマンドを使い、(最新の tar ファイルのように) 既存のソース・ツリーを、CVS サーバーからの最新ソースに更新します:

  • setenv CVSROOT :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot
  • cvs login (CVS サーバー・ログインのプロンプトに応答)
  • cd mozilla
  • cvs -z3 checkout -PA mozilla/client.mk
  • make -f mozilla/client.mk checkout MOZ_CO_FLAGS=-PA

その他の環境

Win32、Mac、UNIX、Linux、BSD、および他のプラットフォームで明示的に作成するときの指示は、ビルド・ページ (参考文献を参照) を調べてください。ここまでの指示すべてに実際に従い、自分のコンピューターで機能するビルド環境を正しく設定してきたのであれば、表彰モノです (少しお休みください)!自分で自分を誉めていただき、ここからは実際に生産的な作業を始めましょう。

アプリケーションでの XPCOM の使用可能化

アプリケーションが実際に XPCOM コンポーネントを使い始める前に、XPCOM フレームワークが機能するように、ロードして初期設定しておく必要があるライブラリー群があります。次に示すのは、そのことを実行するサンプル・アプリケーションです:

リスト 1. 必要なライブラリーをロードして初期設定するサンプル・アプリケーション

#include <stdio.h>
#include <nsIServiceManager.h>
#include <nsISomething.h>
int main()
{
   static const char szContractId[] =
      "Your component's contract ID goes here";
   nsresult rv;
   // Initialize XPCOM and check for failure ...
   rv = NS_InitXPCOM(nsnull, nsnull);
   if ( NS_FAILED(rv) )
   {
      printf("Calling NS_InitXPCOM returns [%x].\n", rv);
      return -1;
   }
   // optional autoregistration - forces component manager to check for new components.
   (void)nsComponentManager::AutoRegister(nsIComponentManager::NS_Startup, nsnull);
   // Create an instance of our component
   nsCOMPtr<nsisomething> mysample = do_CreateInstance(szContractId, &rv);
   if ( NS_FAILED(rv) )
   {
      printf("Creating component instance of %s fails.\n", szContractId);
      return -2;
   }
   // Do something useful with your component ...
   // (main body of code goes here)
   // Released any interfaces.
   // Shutdown XPCOM
   NS_ShutdownXPCOM(nsnull);
   return 0;
}

重要な呼び出しは 2 つあり、NS_InitXPCOMNS_ShutdownXPCOM です。XPCOM のコア・ライブラリーは、普通はアプリケーションと同じディレクトリーにあり、"components" という別のサブディレクトリーが必要になります。XPCOM を初期化したら、生産的な作業を実行するときに直接に関係する 2 大コンポーネントは、コンポーネント・マネージャーとサービス・マネージャーです。AutoRegister への呼び出しは実際には任意指定で、これが本当に必要になるのは、新しいコンポーネントをインストールするときだけです。

上記の例では、ブラウザー・サポートを必要としないスタンドアロン・アプリケーションを想定しています。nsISomething は、いくつかの実インターフェースにとっては見せかけに過ぎません。このインターフェースを利用する現実のアプリケーション・コードは、上記のサンプルで "main body of code goes here" とコメントされている位置に置かれます。

コンポーネント・マネージャー

コンポーネント・マネージャーは、名前が示すとおりのことを行います。すなわち、現在どのコンポーネントがインストールされているか、また、特定のコンポーネントを作成するのにどの DLL または共用ライブラリーをロードすべきかを記憶しています。前述の components サブディレクトリーは、コンポーネント・マネージャーが、コンポーネントを見つけようとする場所ということになります。上記の AutoRegister ステップでこのディレクトリーをスキャンして、まだ登録されていないコンポーネントを探し、記述項目を専用のマップ・ファイルに追加します。どの DLL または共用ライブラリーをロードするかについては、すでにマップからわかっているので、この後にコンポーネントに対して出される要求はずっと早くなります。コンポーネントは、次の 2 つのいずれかで識別されます: クラス ID (CID) として知られている 128 ビットの UUID、またはコントラクト ID として知られている短いテキスト名。

MSCOM プログラマーへの注: コントラクト ID は、MSCOM のプログラム ID (ProgID) と機能的に同等です。

ここでは、IDL のコンポーネント・マネージャーによって提供されるコア・メソッドをいくつか紹介します。最初のものは、指定したコントラクト ID のクラス ID を検索します。同じクラスのコンポーネントを大量に作成する計画で、コンポーネントのコントラクト ID しか知らない場合、まずこのメソッドを呼び出し、createInstance に対するその後の呼び出しで、短く、速いクラス ID を使うことにより、パフォーマンスを改善できます。

void contractIDToClassID(in string aContractID, out nsCID aClass);

次のメソッドは、上記の逆を行うだけです:

string CLSIDToContractID(in nsCIDRef aClass, out string aClassName);

次のメソッドは、いくつかのコンポーネントが登録されていて使用できることを確認します:

boolean isRegistered(in nsCIDRef aClass);

次の 2 つのメソッドは、任意の XPCOM コンポーネントをロードするために、面倒なすべての作業を実行してくれます。コンポーネントを識別するときの選択を、createInstance のクラス ID によって、またはcreateInstanceByContractIDcontractID によって、最初のパラメーターに指定します。2 番目のパラメーターaDelegate は、集約という作業を行っている場合にだけ必要で、普通は nsnull にセットされています。3 番目のパラメーターは、インターフェース IID です。

voidPtr createInstance(in nsCIDRef aClass, in nsISupports aDelegate, in nsIIDRef aIID);
voidPtr createInstanceByContractID(in string aContractID, in nsISupports aDelegate, in nsIIDRef IID);

コンポーネント・マネージャー・メソッドのすべての IDL ソースは、nsIComponentManager.idl にあります。

サービス・マネージャー

XPCOM サービスは、いくつかの本の中でシングルトン・オブジェクトとして言及されています。サービスを何回要求したとしても、あなたは同じコンポーネントへのインターフェースを受け取ります。すべてのサービスの中でも最大のサービス、すなわちコンポーネント・マネージャーについてはすでに見ました。遠まわしに言うと、サービス・マネージャーそのものがサービスと言えます。要するに、サービス・マネージャーは、サービスのロードとアンロードを担当します。すでにロードされたサービスへの要求を出すと、賢いサービス・マネージャーは、別のオブジェクトを構成しようとするのではなく、既存のサービスへの別のポインターを戻します。この動作が、要求ごとに新しいコンポーネントを新調するコンポーネント・マネージャーとどのように違うかに注目してください。サービスは、リスト 2 で示されているように、普通は NS_WITH_SERVICE マクロを使って要求されます。

リスト 2. サービス要求
{  // enter scope of service smart pointer ...
   NS_WITH_SERVICE(nsIMyService, service, kMyServiceCID, &rv);
   if (NS_FAILED(rv)) return rv;
   service->DoSomething(...);    // use my service
} // leaving scope of service smart pointer ...

NS_WITH_SERVICE マクロは、nsCOMPtr を使ってスマート・ポインターを作成することに注目してください。サービスの例がいくつか表 2 にリストされています。

表 2. サービスの例
  • LDAP
  • WebShell
  • JSRuntime
  • Editor
  • EventQueue
  • RDF
  • SMTP
  • IMAP
  • POP3
  • NNTP
  • DNS
  • Error
  • Logging

カテゴリー・マネージャー

コンポーネント・マネージャーとサービス・マネージャーは、コントラクト ID またはクラス ID を与えられたコンポーネントを取ってきます。しかし、そのどちらの ID もわからないコンポーネントを見つけるときにはどうしますか?この質問の答えは、カテゴリー・マネージャーです。カテゴリー・マネージャーには、カテゴリーに分けられたクラス ID のディレクトリーがあります。ここで言う「ディレクトリー」とは、ディスク・ドライブのディレクトリーではなく、(イエロー・ページのような) 電話帳を思い浮かべてください。電話帳のような形式を使うと、その地域のすべてのホテルを探したい場合に、電話帳の「ホテル」の項目を探すことができます。

たとえば、あなたがさまざまなワード・プロセッシング機能を備え、汎用のインターフェース群を使って複数の文書タイプを扱える、出来の良いエディターを作成したとします。サポートするために選んだ文書タイプは、テキスト、HTML、RTF および PDF です。しかし、文書ハンドラー群は「文書ハンドラー」カテゴリーに登録され、使用可能な文書タイプを判別するために、いつも文書ハンドラー・カテゴリーをチェックするようにプログラムを作成しました。

あなたの友達が、あなたのプログラムをどうしても WordPerfect ファイル対応にすると決心し、同じインターフェース群をインプリメントする新しい文書ハンドラー・コンポーネントを作ってきて、文書ハンドラー・カテゴリーの下に登録します。あなたのプログラムを使うユーザーは、友達の新しい文書ハンドラーを、ダウンロードし、インストールし、使い始められるようになりました。あなたの側では余分の作業をする必要はありません。

あるカテゴリーの下にグループ化されたコンポーネントは、事前定義されたインターフェース群のように、普通は何らかの共通点があるものです。それ自身をカテゴリーの下に登録するコンポーネントにとって、カテゴリーというものは暗黙の契約になります。カテゴリーはオブジェクトを独立させるための、非常に強力な方法です。なぜなら、カテゴリーを利用するコードは、インターフェースについて知ろうとするだけであり、特定のインプリメンテーションからは分離することができるためです。このような威力があるのですが、カテゴリーは XPCOM の中で期待したほど使われていない最たる特徴の一つです。

結論

Mozilla ソース・ツリーを作成できるようになり、実際にコンポーネントのユーザーになったら、向かうところ敵なしであることを堂々と宣言なさってください。ほんの少しの知識でもこれほど心強いのですが、このシリーズの次の 2 つの記事を読めば、さらにあなたの知識を完成させることができます。コンポーネントを作成する力をつけるだけでなく、自分自身のプログラムを台無しにしたり他人のアプリケーションを壊してしまうことなく、作成できるようになるでしょう。


ダウンロード可能なリソース


関連トピック

  • これは、XPCOM についての 5 回連続シリーズの第 3 回です。他の回は次のようなものです:
  • この記事は Mozilla の CVS を利用しています。たくさんの開発者がすべて同じコードで作業できるようにする、他の共通ソース・コード・ツールには、次のものがあります:
  • 多くの環境で共通のツールを使うことにより、同じソースを別のプラットフォームでも同じ方法を使ってコンパイルできます。Windows ユーザーは、次のいくつかのツールをダウンロードしてインストールする必要があります:
  • Infozip は、次の 2 つの部分に分けられます:
    • unzip
    • zip
  • Linux 配布版では、配布物の一部として次のツールが付属します。広く使用されている Linux 配布版には、次のものがあります:
  • 何かのプラットフォームで問題が生じている場合、Mozilla サイトのMozilla Build Info page にアクセスすると役立つかもしれません。
  • Windows ユーザーも、Microsoft Visual Studio Service(日本語サイト) かMicrosoft Windows Installer package をダウンロードする必要があるかもしれません。
  • Netscape Wintools も便利です。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=244518
ArticleTitle=XPCOM: 第 3 回: XPCOM のセットアップ
publish-date=03012001