JPH10507016A - ソフトウェア・コンパイル・ユニットを条件付きでコンパイルするシステム、方法およびコンパイラ・プリプロセッサ - Google Patents

Abstract

(57)【要約】 複数のソース・コード・モジュールを有するコンパイル・ユニットを条件付きで再コンパイルするシステム、方法およびコンパイラ・プリプロセッサ（１１４）は、ソース・コード・モジュールの１つを選択することによって動作し、選択されたソース・コード・モジュールの新しい圧縮表現を生成する必要があるか否かを判断する。その生成が必要であると判断されれば、選択されたソース・コード・モジュールの新しい圧縮表現が生成される。選択されたソース・コード・モジュールの新しい圧縮表現と選択されたソース・コード・モジュールの元の圧縮表現との間の変更が判別される。これらの変更の各々は互換性のある変更または互換性のない変更と分類される（９２６）。互換性のない変更はコンパイル・ユニットの再コンパイルを必要とする変更である。互換性のある変更はコンパイル・ユニットの再コンパイルを必要としない変更である。変更のいずれかが互換性のない変更と分類されているときにコンパイル・ユニットは再コンパイルされる（８１６）。

Description

【発明の詳細な説明】 ソフトウェア・コンパイル・ユニットを条件付きでコンパイルする システム、方法およびコンパイラ・プリプロセッサ 発明の背景 発明の分野 本発明は、一般的にはコンパイル・ユニット（単位）をコンパイルすることに 関し、より具体的には、コンパイル・ユニットのコンポーネントが互換性のない 形で変更されたときのみコンパイル・ユニットを再コンパイルすることに関する 。 関連技術 ソフトウェア・コンパイル・ユニットは、「メイン」ソフトウェア・プログラ ムと１つまたは２つ以上のヘッダ・ファイルを含んでいるのが代表的である。ヘ ッダ・ファイルは「メイン」プログラムに置かれている（またはヘッダ・ファイ ル自体に置かれている）該当のソフトウェア・ステートメントを使用して明示的 にコンパイル・ユニットの中に組み込まれている。例えば、周知のＣコンピュー タ・プログラミング言語では、ヘッダ・ファイルをコンパイル・ユニットに組み 込むために「インクルード("include")」ステートメントが使用されている。例 えば、次のステートメントは、 #include "a.h" "a.h"と名付けたヘッダ・ファイルをコンパイル・ユニットに組み入れるために 「メイン」プログラムの中に挿入されている。これらはインクルード・ステート メントを使用してコンパイル・ユニットに挿入されるので、ヘッダ・ファイルは 「インクルード・ファイル(include file)」とも呼ばれている。なお、本明細書 では、これらの用語（つまり、「ヘッダ・ファイル」と「インクルード・ファイ ル」）は同じ意味をもつものとして使用されている。 従来は、「メイン」プログラムはコンパイル・ユニットがコンパイルされると 、常にそのヘッダ・ファイルのすべてと一緒にコンパイルされている。周知のＵ ＮＩＸシステムでは、そのコンポーネント部分のいずれかが（つまり、「メイン 」プログラムおよび／またはヘッダ・ファイルのいずれか）が変更されたときだ け、"make"ユーティリティがコンパイル・ユニットをコンパイルするように動作 している。 しかるに、そのコンポーネント部分の１つまたは２つ以上が、コンパイル・ユ ニットがコンパイルされた最後の時刻以後に変更されなかった場合でも、コンパ イル・ユニットを再コンパイルしないで済むことがよくある。例えば、コンパイ ル・ユニットのコンポーネントのフォーマットだけが変更された場合は、コンパ イル・ユニットを再コンパイルする必要はない。しかし、従来は、そのコンポー ネント部分になんらかの変更が行なわれると、常にコンパイル・ユニットが再コ ンパイルされている。従って、従来のコンパイラは不要なコンパイル・オペレー ションを行なっていた。その結果、従来のコンパイラによるシステム資源の利用 は非効率的であった。 発明の概要 要約して説明すると、本発明は、複数のソース・コード・モジュールからなる コンパイル・ユニット(compilation unit)を条件付きで再コンパイル(condition al recompilation)するシステムおよび方法を目的としている。本発明はソース ・コード・モジュールの１つを選択し、選択されたソース・コード・モジュール の新しい圧縮表現(new condensed representation)を生成する必要があるかどう か判断することによって動作する。次に、本発明は、選択されたソース・コード ・モジュールの新しい圧縮表現と選択されたソース・コード・モジュールの元の 圧縮表現(old condensed representation)との間に変更があるかどうかを判別す る。これらの変更の各々は、互換性のある変更(compatible change)または互換性のない変更(incompatible change)のどちらかに分類される 。互換性のない変更とは、コンパイル・ユニットの再コンパイルを必要とする変 更である。互換性のある変更とは、コンパイル・ユニットの再コンパイルを必要 としない変更である。本発明によれば、コンパイル・ユニットの再コンパイルは 、変更のいずれかが互換性のない変更であると分類されたときだけ行なわれる。 本発明のその他の特徴および利点は、本発明の種々実施例のオペレーションお よび構造と共に、添付図面を参照して以下で詳しく説明する。なお、添付図面に おいて、同一または機能的に類似のエレメントは類似の参照符号を付けて示され ている。 図面の簡単な説明 以下、添付図面を参照して本発明を説明する。図面において、 図１は本発明の好適実施例によるコンピュータ・システムを示すブロック図で ある。 図２、図３Ａ〜図３Ｃ、および図４〜図７は、図１のコンピュータ・システム の記憶デバイスにストアできるファイルのタイプと、そのようなファイルの好ま しいフォーマットを示す図である。 図８〜図１０は本発明の好ましいオペレーションを示すフローチャートである 。 図１１〜図１４は本発明のオペレーションを説明するために使用されるタイム ラインである。 図１５は図１４に示すタイムラインに関する解析の要約テーブルである。 好適実施例の詳細な説明 図１は本発明の好適実施例によるコンピュータ・システム１０２を示すブロッ ク図である。好ましくは、コンピュータ・システム１０２は、シリコン・グ ラフィックス(Silicon Graphics)社(Mountain View，CA)製のIrix 5.2オペレー ティング・システムが稼働しているインディ・ワークステーション(Indy Workst ation)が使用されているが、これとは別に、他の適当なコンピュータ・システム を使用することも可能である。コンピュータ・システム１０２はバス１０６に接 続されたプロセッサ１０４を搭載している。好ましくは、プロセッサ１０４はSi licon Graphics社製のMIPS R4000シリーズＣＰＵであるが、これとは別に、他の 適当なＣＰＵを使用することも可能である。 バス１０６には記憶デバイス１０８も接続されており、これはランダムアクセ スメモリ(random access memory - ＲＡＭ)、リードオンリメモリ(read only me mory - ＲＯＭ)、二次記憶デバイス(secondary storage device)（ハードディス クなど）、またはこれらのデバイスの任意の組合せにすることが可能である。 プロセッサ１０４はコントロール・ロジック１１０に従って動作する。このよ うなコントロール・ロジック(control logic)１１０は好ましくは、ソフトウェ ア・コンパイラ１１２やコンパイラ・プリプロセッサ(compiler pre-processor) １１４のように、記憶デバイス１０８にストア（格納）された１つまたは２つ以 上のコンピュータ・プログラムを表している。従って、プロセッサ１０４は、こ のようなコンピュータ・プログラムに含まれる命令に従って動作する。このよう なコンピュータ・プログラムは好ましくはＣ、Ｃ++、Pascalおよび／またはアセ ンブラで書かれているが、これとは別に、他の適当なコンピュータ・プログラミ ング言語を使用することも可能である。 なお、ソフトウェア・コンパイラ１１２とコンパイラ・プリプロセッサ１１４ は単一のコンピュータ・プログラムの部分を表している場合もあれば、異種のコ ンピュータ・プログラムを表している場合もある。同様に、コントロール・ロジ ック１１０はハードウェア・ステートマシン（hardware state machine）で実現 されている場合もある。 ある実施例では、本発明は、コントロール・ロジック１１０がそこに記録され ているコンピュータが読取り可能な媒体(computer readable media)を備えたコ ンピュータ・プログラム・プロダクトになっている。コントロール・ロジック １１０は公知の手段を使用して記憶デバイス１０８にロードされ、プロセッサ１ ０４によって実行される。 記憶デバイス１０８にはソース・ファイル１１６もストアされている。図２に 示すように、ソース・ファイル１１６は、例えば、「メイン」ソース・ファイル ２０２（図２では、"main.c"と名付けられている）を含んでいる。「メイン」ソ ース・ファイル２０２の例の一部は図４に示されている。この例示の「メイン」 ソース・ファイル２０２は３つの「インクルード("include")」ステートメント を含んでいるが、これらのステートメントは公知のように実行されてインクルー ド・ファイル"a.h"、"b.h"、および"c.h"のコードを「メイン」ソース・ファイル ２０２に組み込むように働く。 再び図１を参照するに、記憶デバイス１０８はヘッダ・ファイル１２０（イン クルード・ファイルおよびソース・コード・モジュールとも呼ばれる）もストア している。図３Ｂに示すように、ヘッダ・ファイル１２０は"a.h"、"b.h"、"c.h "、"d.h"、および"e.h" ヘッダ・ファイルを含んでいるが、これらのヘッダ・フ ァイルは、それぞれ、参照符号３０４，３０６，３０８，３１０、および３１２ で示されている。"a.h"ヘッダ・ファイルのように、例示のヘッダ・ファイルの 部分は図５に示されている。この例示の"a.h"ヘッダ・ファイル３０４は種々の 宣言(declaration)ステートメント（図５には、〈first declaration〉および〈 second declaration〉と名付けられている）を含んでいる。また、この例示の"a .h"ヘッダ・ファイル３０４は２つの「インクルード」ステートメントも含んで おり、これらのステートメントは公知のように実行されて、"d.h"ヘッダ・ファ イル３１０と"e.h"ヘッダ・ファイル３１２のコードを"a.h"ヘッダ・ファイル３ ０４に組み込むように働く。以上から理解されるように、ヘッダ・ファイル１２ ０がソース・コード・モジュールを表わしているのは、これらがソース・コード （例えば、バイナリ・コードではなく）を含んでいるからである。 再び図１を参照するに、記憶デバイス１０８には、事前コンパイル済み(pre-c ompiled)ヘッダ・ファイル１２２もストアされている。この分野の当業者ならば 理解されるように、事前コンパイル済みヘッダ・ファイルはヘッダ・ファイルの 圧縮バイナリ表現(condensed，binary representation)になっている。好まし くは、事前コンパイル済みヘッダ・ファイルの形態は、コンパイラがコンパイル 時の期間にソース・ステートメントを内部表現するために使用する形態と同一に なっている。このような事前コンパイル済みヘッダ・ファイルは、事前コンパイ ル済みヘッダ・ファイルに含まれる宣言の、コンパイラによる内部処理の多くが 事前に行なわれているので（事前コンパイル済みファイルの作成時に）、コンパ イラへの読込みがオリジナル・ヘッダ・ファイルよりも高速化されている。図３ Ｃに示すように、事前コンパイル済みヘッダ・ファイルは、それぞれが"a.h"、" b.h"、"c.h"、および"d.h"ヘッダ・ファイル３０４，３０６，３０８，３１０に 対応している"a.x"、"b.x"、"c.x"、および"d.x"事前コンパイル済みヘッダ・フ ァイル３１４，３１６，３１８，３２０を含んでいる。 図６は"a.x"ファイル３１４のように、事前コンパイル済みヘッダ・ファイル の例を示している。"a.x"ファイル３１４はフィールド６０６と６１０を含み、 これらのフィールドは、"a.h"ヘッダ・ファイルに入っている宣言のコンパイラ 内部表現（図５には、〈first declaration〉および〈second declaration〉と 名付けられている）を収めている。"a.x"ファイル３１４はフィールド６０８と ６１２も含んでおり、これらのフィールドは、"d.h"と"c.h"ヘッダ・ファイル３ １０，３１２の組込みを可能にする（ソフトウェア・リンカの動作期間に）情報 を収めている。さらに、"a.x"ファイル３１４はヘッダ・ファイル６０４を含ん でいる。ヘッダ・ファイル６０４は"a.x"ファイル３１４の以前のバージョンに 関するヒストリ（活動記録）情報(historical information)を収めている。この ヘッダ・ファイル６０４については、以下で詳しく説明する。 再び図１を参照するに、記憶デバイス１０８には、オブジェクト・ファイル(o bject file)もストアされている。オブジェクト・ファイルはマシン命令（機械 語命令）が集まったものである。１つまたは２つ以上のオブジェクト・ファイル が１つにリンクされて、実行可能プログラムが作られる。図３Ａに示すように、 このようなオブジェクト・ファイル１１８は、「メイン」オブジェクト・ファイ ル３０２（図３では、"main.o"と名付けている）を含んでおり、これは「メイン 」ソース・ファイル２０２とそのヘッダ・ファイルのコンパイル済みバイナリ・ バージョンである。 本発明の好適実施例によれば、コンパイラ・プリプロセッサ１１４とソフトウ ェア・コンパイラ１１２はコンパイル・ユニットをコンパイルして、コンパイル ・ユニットのコンパイル済みオブジェクト・コード・バージョン（つまり、オブ ジェクト・ファイル）を生成するように動作する。ついで、ソフトウェア・リン カ（図示せず）を使用すると、公知のように、コンパイル・ユニットのオブジェ クト・コード・バージョンから実行可能ファイル(executable file)を生成する ことができる。なお、このソフトウェア・リンカは本発明の一部ではないので、 ここで詳しく説明することは省略する。実行可能ファイルは、図１に示すコンピ ュータ・システム１０２のように、コンピュータ・システムによって実行される 。 以下では、コンパイラ・プリプロセッサ１１４とソフトウェア・コンパイラ１ １２のオペレーションの概要について説明する。なお、説明の便宜上、コンパイ ルされるコンパイル・ユニットは、次のようなソフトウェア・エレメント(softw are elements)を含んでいるものとする。すなわち、図４に示す「メイン」ソー ス・ファイル２０２と、図３Ｂに示す"a.h"、"b.h"、"c.h"、"d.h"、および"e.h "ヘッダ・ファイル３０４，３０６，３０８，３１０，３１２であるが、その場 合、"a.h"ヘッダ・ファイル３０４の詳細は図５に示すようになっている。 このコンパイル・ユニットのコンパイルは、一般的に次のように行なわれる。 まず、コンパイラ・プリプロセッサ１１４はコンパイル・ユニットを解析し、そ のコンパイル・ユニットを再コンパイルする必要があるかどうかを判断する。一 般的には、コンパイル・ユニットがコンパイルされた最後の時刻以後にコンパイ ル・ユニットが変更されていなければ、そのコンパイル・ユニットを再コンパイ ルする必要はない。また、本発明によれば、コンパイル・ユニットがコンパイル された最後の時刻以後にコンパイル・ユニットが変更されていても、その変更が 「互換性のある変更」である限り、そのコンパイル・ユニットを再コンパイルす る必要がない。なにが「互換性のある変更」であるかについては、以下で説明す る。 次に、コンパイルが必要であると判断されていれば、コンパイラ１１２はコン パイル・ユニットをコンパイルする。コンパイラ１１２は、公知の、適切なコン パイル技法を用いてコンパイル・ユニットをコンパイルする。このようなコンパ イル技法は言語によって特定されているものである。例えば、コンパイルを必要 とするヘッダ・ファイルがＣ++コンピュータ・プログラミング言語で書かれてい れば、コンパイラ１１２はＣ++コンピュータ・プログラミング言語に見合った公 知のコンパイル技法を用いてそのコンパイル機能を実行する。 以下では、コンパイラ・プリプロセッサ１１４はコンパイル・ユニットをどの ように解析して、コンパイル・ユニットの再コンパイルが必要かどうかを判断す るかを、図８に示すフローチャートを参照しながら説明する。説明の便宜上、フ ローチャート８０２のオペレーションは、それが適切であれば、上記の例を用い て説明することにする。具体的には、以下の説明では、コンパイルされるコンパ イル・ユニットは、図４に示す「メイン」ソース・ファイル２０２および図３Ｂ に示す"a.h"、"b.h"、"c.h"、"d.h"、および"e.h"ヘッダ・ファイル３０４，３ ０６，３０８，３１０，３１２を含んでいるものとし、その場合、"a.h"ヘッダ ・ファイル３０４の詳細は図５に示すようになっている。フローチャート８０２ はステップ８０４から始まり、そこでコントロール（制御）は即時にステップ８ ０５に渡される。 ステップ８０５において、コンパイラ・プリプロセッサ１１４はソース・ファ イルのオブジェクト・コード・バージョン（つまり、オブジェクト・ファイル） が存在するかどうかを判断する。また、コンパイラ・プリプロセッサ１１４はソ ース・ファイルとその中で参照されているマクロがコンパイル・ユニットがコン パイルされた最後の時刻以後に未変更のままであるかどうかも判断する。(1)ソ ース・ファイルのオブジェクト・コード・バージョンが存在しないか、あるいは (2)その中で参照されているマクロがコンパイル・ユニットがコンパイルされた 最後の時刻以後に変更されていれば、ステップ８０７が実行され、そこでコンパ イラ・プリプロセッサ１１４は再コンパイル・フラグ(recompile flag)（これに ついては、以下に述べる）を「真(true)」にセットする。ここで説明している例 では、コンパイラ・プリプロセッサ１１４は、"main.c"２０２（図２）のオブジ ェクト・ファイル表現である、"main.o"３０２（図３Ａ）が存在するかどうか を、ステップ８０５で判断する。"main.c"２０２とその中で参照されているマク ロが"main.c"がコンパイルされた最後の時刻以後に変更されていないとすれば、 ステップ８０６が実行される。 本発明によれば、再コンパイル・フラグ(recompile flag)は各コンパイル・ユ ニットと関連づけられている。この再コンパイル・フラグは、好ましくは、記憶 デバイス１０８のような、ランダムアクセスメモリ（ＲＡＭ）に保存されている 。再コンパイル・フラグは、コンパイル・ユニットを再コンパイルする必要があ るかどうかを示している。具体的に説明すると、再コンパイル・フラグがセット されていれば（つまり、値が"1"にセットされていれば）、コンパイル・ユニッ トを再コンパイルする必要があることを意味する（ステップ８１６。これは下述 する）。ヘッダ・ファイルと関連づけられた再コンパイル・フラグがクリアされ ていれば、そのヘッダ・ファイルを再コンパイルする必要があることを意味する （ステップ８１５。これは下述する）。 ステップ８０６で、コンパイラ・プリプロセッサ１１４は、コンパイル・ユニ ットに関連づけられた再コンパイル・フラグをクリアする（つまり、値をゼロま たは論理「偽(false)」にセットする）。 ステップ８０８で、コンパイラ・プリプロセッサ１１４はコンパイル・ユニッ トの中で参照されているヘッダ・ファイル３０４，３０６，３０８，３１０，３ １２の１つを選択し、解析する。説明の便宜上、"d.h"ヘッダ・ファイル３１０ がこのステップ８０８で選択されたものとする。 ステップ８１０で、コンパイラ・プリプロセッサ１１４はステップ８０８で選 択されたヘッダ・ファイル（つまり、"d.h"ヘッダ・ファイル３１０）を解析し 、このヘッダ・ファイルが変更されたことによる、コンパイル・ユニットの再コ ンパイルが必要かどうかを判断する。コンパイラ・プリプロセッサ１１４がコン パイル・ユニットの再コンパイルが必要であると判断すると、プリプロセッサ１ １４は再コンパイル・フラグを論理「真」にセットする。プリプロセッサ１１４ がステップ８１０をどうように実行するかは、以下で詳しく説明する。 ステップ８１２で、プリプロセッサ１１４は処理すべきヘッダ・ファイル３０ ４，３０６，３０８，３１０，３１２が他にもあるかどうかを判断する。ス テップ８０８で以前に選択され、解析されたヘッダ・ファイル３０４，３０６， ３０８，３１０，３１２は再処理する必要はない。処理すべきヘッダ・ファイル が他にも残っていれば、コントロールはステップ８０８に戻され、残っているヘ ッダ・ファイルの１つを選択する。 ステップ８１４で、ヘッダ・ファイルのすべてが処理されると（この判断はス テップ８１２で行なわれる）、プリプロセッサ１１４は、（コンパイル・ユニッ トに関連づけれた）再コンパイル・フラグが論理「真」にセットされているかど うかを判断する。再コンパイル・フラグがセットされていなければ、ステップ８ １５に示すようにコンパイル・ユニットを再コンパイルする必要はない。 再コンパイル・フラグがセットされていれば、プリプロセッサ１１４は、ステ ップ８１６において、コンパイル・ユニットをコンパイルするようにコンパイラ １１２に指示する。 ステップ８１５または８１６のどちらかが実行されたあと、フローチャート８ ０２のオペレーションはステップ８１８に示すように完了する。 次に、コンパイラ・プリプロセッサ１１４が、選択されたヘッダ・ファイル（ ステップ８０８で選択されたもの）をステップ８１０でどのように解析するかを 、図９のフローチャート９０２を参照しながら説明する。フローチャート９０２ はステップ８１０を実行するときのプリプロセッサ１１４のオペレーションを示 している。フローチャート９０２はステップ９０４から開始し、そこでコントロ ールは即時にステップ９０６に渡される。 ステップ９０６で、プリプロセッサ１１４は、選択されたヘッダ・ファイルに 対応する事前コンパイル済みヘッダ・ファイルが存在するかどうかを判断する。 そのような事前コンパイル済みヘッダ・ファイルが存在すれば、ステップ９０８ が実行される。存在しなければ、ステップ９３０が実行される。 例えば、"e.h"ヘッダ・ファイル３１２がステップ８０８で選択されたものと する（図８）。この場合は、プリプロセッサ１１４は、選択されたヘッダ・ファ イル（つまり、"e.h"ヘッダ・ファイル３１２）に対応する事前コンパイル済み ヘッダ・ファイルが存在しないものと、ステップ９０６で判断する（図３Ｃを参 照）。その結果、ステップ９３０が実行される。ステップ９３０で、プリプロ セッサ１１４は、選択されたヘッダ・ファイル（つまり、"e.h"ヘッダ・ファイ ル３１２）に対応する事前コンパイル済みヘッダ・ファイル（"e.x"と名付けて いる）を公知の言語固有のコンパイル技法を用いて生成するようにコンパイラ１ １２に指示する。この新しい事前コンパイル済みヘッダ・ファイルは他の事前コ ンパイル済みヘッダ・ファイル１２２と一緒に記憶デバイス１０８にストアされ る。ステップ９３２で、プリプロセッサ１１４は再コンパイル・フラグをセット する。ステップ９３２が実行されたあと、フローチャート９０２のオペレーショ ンはステップ９１６に示すように完了する。 次に、例えば、"b.h"ヘッダ・ファイル３０６がステップ８０８で選択された ものとする（図８）。この場合は、プリプロセッサ１１４は、選択されたヘッダ ・ファイル（つまり、"b.h"ヘッダ・ファイル３０６）に対応する事前コンパイ ル済みヘッダ・ファイルが存在するものと、ステップ９０６で判断する（図３Ｃ を参照）。その結果、ステップ９０８が実行される。 ステップ９０８で、プリプロセッサ１１４は選択されたヘッダ・ファイルに対 応する事前コンパイル済みヘッダ・ファイルがあらかじめ定義された、いくつか の必要条件を満足しているかどうかを判断する。事前コンパイル済みヘッダ・フ ァイルが事前定義された必要条件のすべてを満足していれば、そのヘッダ・ファ イルの事前コンパイル済みヘッダ・ファイルは再生成する必要がない。逆に、事 前コンパイル済みヘッダ・ファイルが事前定義の必要条件のすべてを満足してい なければ、現行の事前コンパイル済みヘッダ・ファイルは更新されていないので (out-of-date)、ヘッダ・ファイルの事前コンパイル済みヘッダ・ファイルを再 生成する必要がある。 プリプロセッサ１１４がステップ９０８をどのように実行するかは図１０のフ ローチャート１００２に示されている。このフローチャート１００２はステップ １００４から始まり、そこでコントロールは即時にステップ１００６に渡される 。 ステップ１００６で、プリプロセッサ１１４は、事前コンパイル済みヘッダ・ ファイルが選択されたヘッダ・ファイルより新しいかどうか（つまり、事前コン パイル済みヘッダ・ファイルの作成日が選択されたヘッダ・ファイルの作成日よ りも時間的に最近であるかどうか）を判断する。基本的には、ステップ１００６ でプリプロセッサ１１４は選択されたヘッダ・ファイルが事前コンパイル済みヘ ッダ・ファイルが生成された最後の時刻以後に変更されたかどうかを判断する。 選択されたヘッダ・ファイルが事前コンパイル済みヘッダ・ファイルが生成され た最後の時刻以後に変更されていれば（つまり、事前コンパイル済みヘッダ・フ ァイルが選択されたヘッダ・ファイルよりも新しくなければ）、プリプロセッサ １１４は選択されたヘッダ・ファイルの事前コンパイル済みヘッダ・ファイルを 再生成する必要があると判断する。従って、プリプロセッサ１１４は事前コンパ イル済みヘッダ・ファイルが必要条件を満足していないと判断する（ステップ１ ０１２）。そうでなければ、ステップ１００８が実行され、次の必要条件と突き 合わせて事前コンパイル済みヘッダ・ファイルが評価される。 ステップ１００６の間におけるプリプロセッサ１１４のオペレーションはそれ ぞれ図１１と１２に示すタイムライン１１０２と１２０２の例に示されている。 まず、図１２に示すタイムライン１２０２から説明することにする。タイムライ ン１２０２に示すように、選択されたヘッダ・ファイル（"b.h"ヘッダ・ファイ ル３０６）は時刻t1に作成され、時刻ｔ３に変更されている。対応する事前コン パイル済みヘッダ・ファイル（"b.x"事前コンパイル済みヘッダ・ファイル３１ ６）は時刻ｔ２に最後に変更されている。プリプロセッサ１１４は時刻ｔ４にス テップ１００６を実行する。タイムライン１２０２を基準にして、プリプロセッ サは事前コンパイル済みヘッダ・ファイルが選択されたヘッダ・ファイルよりも 新しくないと、ステップ１００６で判断する。従って、（上述した）ステップ１ ０１２が実行される。 図１１のタイムライン１１０２に示すように、選択されたヘッダ・ファイル（ "b.h"ヘッダ・ファイル３０６）は時刻ｔ1 に作成されている。対応する事前コ ンパイル済みヘッダ・ファイル（"b.x"ヘッダ・ファイル３１６）は時刻ｔ２に 最後に生成されている。プリプロセッサ１１４は時刻ｔ３にステップ１００６を 実行する。タイムライン１１０２を基準にして、プリプロセッサ１１４は事前コ ンパイル済みヘッダ・ファイルが選択されたヘッダ・ファイルよりも新しいと、 ステップ１００６で判断する。従って、ステップ１００８が実行される。 ステップ１００８で、プリプロセッサ１１４は、選択されたヘッダ・ファイル に収められたマクロ（もしあれば）が対応するヘッダ・ファイルが最後に生成さ れたときと同じであるかどうかを判断する。代表例として、マクロは次のように 定義されている。 #define macroname expansion tokens または #define macroname（parameter,parameter）expansion tokens 上記において、expansion tokensは、コンパイルされる言語で合法的(legal)で あるトークン（ワード、シンボルなど）の集合を表している。コンパイラ１１２ はこれらのマクロ名の１つに一致するワードをソースの中で見つけると（この定 義の後に続くどこかで）、そのワードと、そのあとに続くパラメータ・リストが あれば、そのリストをマクロ定義に指定されたexpansion tokens（展開トークン ）で置き換える。マクロはこの分野では公知である。 選択されたヘッダ・ファイルに収められたマクロが対応する事前コンパイル済 みヘッダ・ファイルが最後に生成されたときと同じでなければ、プリプロセッサ １１４は、選択されたヘッダ・ファイルの事前コンパイル済みヘッダ・ファイル を再生成する必要があると判断する。従って、プリプロセッサ１１４は事前コン パイル済みヘッダ・ファイルが必要条件を満足していないと判断する（ステップ １０１２）。逆に、選択されたヘッダ・ファイルに収められたマクロが対応する 事前コンパイル済みヘッダ・ファイルが最後に生成されたときと同じであれば、 プリプロセッサ１１４は必要条件のすべてが満足されていると判断する（ステッ プ１０１０）。 再び図９を参照するに、プリプロセッサ１１４が、事前コンパイル済みヘッダ ・ファイルが必要条件を満足していないと、ステップ９０８で判断していれば、 ステップ９１８が実行される。ステップ９１８で、プリプロセッサ１１４は選択 されたヘッダ・ファイルの事前コンパイル済みヘッダ・ファイルを、公知の言語 固有のコンパイル技法を用いて再生成するようにコンパイラ１１２に指示する。 この新しい事前コンパイル済みヘッダ・ファイルは他の事前コンパイル済みヘッ ダ・ファイルと一緒に記憶デバイス１０８にストアされる。このような事前 コンパイル済みヘッダ・ファイル１２２はステップ９０８で解析された元の事前 コンパイル済みヘッダ・ファイル（選択されたヘッダ・ファイルと関連がある） も含んでいる。 ステップ９２０で、プリプロセッサ１１４は新しい事前コンパイル済みヘッダ ・ファイルを元の事前コンパイル済みヘッダ・ファイルと比較し、これらの２フ ァイル間の変更（この変更は最後にコンパイルされた時刻以後の、選択されたヘ ッダ・ファイルの変更を反映している）を記録する。ステップ９２２で、プリプ ロセッサ１１４はこれらの変更の各々を、互換性のある変更または互換性のない 変更のどちらかに分類する。互換性のない変更はコンパイル・ユニットの再コン パイルを必要とする変更である。言い換えれば、選択されたヘッダ・ファイルが 互換性のない変更を含んでいれば、コンパイル・ユニットは再コンパイルしなけ ればならない（すなわち、この変更はコンパイル・ユニットと互換性がないので 、コンパイル・ユニットの再コンパイルが必要になる）。互換性のある変更はコ ンパイル・ユニットの再コンパイルを必要としない変更である。言い換えれば、 選択されたヘッダ・ファイルが互換性のある変更だけを含み、互換性のない変更 を含んでいなければ、コンパイル・ユニットを再コンパイルする必要はない（す なわち、この変更はコンパイル・ユニットと互換性があるので、再コンパイルは 必要でない）。 何を互換性のある変更とみなし、何を互換性のない変更とみなすかは、プログ ラミング言語によって異なっている。例えば、周知のＣコンピュータ・プログラ ミング言語では、次のものが互換性のある変更としている。すなわち、(1)外部 ルーチンと変数の新しいタイプと新しい宣言の追加、(2)ソース・ファイルまた はインクルード・ファイルに入っている既存のソース・コードを変更するような 新マクロの追加、(3)フォーマットの変更、などである。一般的に、上記は周知 のＣ++コンピュータ・プログラミング言語でも互換性のある変更を表している。 Ｃコンピュータ・プログラミング言語では、他の多くの言語の場合と同じように 、次のものが互換性のない変更としている。すなわち、メンバをレコードにまた はクラスに追加すること（Ｃ++などの、オブジェクト指向言語の場合）、メンバ をレコードまたはクラスから削除すること、レコードまたはクラスのメンバの タイプを変更すること、新しいデータ・タイプを追加すること、既存のデータ・ タイプを変更すること、新しい関数を追加すること、などである。他の特定のコ ンピュータ・プログラミング言語の場合の、その他の互換性のある変更と互換性 のない変更は、この分野の当業者に自明のことである。 ステップ９２４で、プリプロセッサ１１４は新しい事前コンパイル済みヘッダ ・ファイル（ステップ９１８で生成されたもの）のヘッダ６０４（図６）を、ス テップ９２０で判別され、ステップ９２２で分類された変更に関するステータス （状況）情報で更新する。ヘッダ６０４の好ましいフォーマットは図７に示され ている。好ましくは、ヘッダ６０４の第１フィールド７０２には、プリプロセッ サ１１４は、新しい事前コンパイル済みヘッダ・ファイルがいつ生成されたかに 対応する日付と時刻をストアする。言い換えれば、プリプロセッサ１１４はステ ップ９１８が実行されたときの日付と時刻をこのフィールド７０２に入れる。ヘ ッダ６０４の第２フィールド７０４には、プリプロセッサ１１４は、最後の互換 性のある変更がいつ行なわれたかに対応する日付と時刻をストアする。例えば、 新しい事前コンパイル済みヘッダ・ファイルが互換性のある変更を含んでいれば 、新しい事前コンパイル済みヘッダ・ファイルがいつ生成されたかに対応する日 付と時刻（つまり、ステップ９１８が実行された時の日付と時刻）は、第２フィ ールド７０４にストアされる。逆に、新しい事前コンパイル済みヘッダ・ファイ ルが互換性のある変更を含んでいなければ、プリプロセッサ１１４は元の事前コ ンパイル済みヘッダ・ファイルのヘッダ６０４の第２フィールド７０４から日付 と時刻情報を抜き出し、その情報を新しい事前コンパイル済みヘッダ・ファイル のヘッダ６０４の第２フィールド７０４にストアする。 ヘッダ６０４の第３フィールド７０６には、プリプロセッサ１１４は最後の互 換性のない変更がいつ行なわれたかに対応する日付と時刻を入れる。例えば、新 しい事前コンパイル済みヘッダ・ファイルが互換性のない変更を含んでいれば、 新しい事前コンパイル済みヘッダ・ファイルがいつ生成されたかに対応する日付 と時刻（つまり、ステップ９１８が実行されたときの日付と時刻）が第３フィー ルド７０６にストアされる。逆に、新しい事前コンパイル済みヘッダ・ファイル が互換性のない変更を含んでいなければ、プリプロセッサ１１４は元の事前コン パイル済みヘッダ・ファイルのヘッダ６０４の第３フィールド７０６から日付と 時刻情報を抜き出し、その情報を新しい事前コンパイル済みヘッダ・ファイルの ヘッダ６０４の第３フィールド７０６にストアする。 ステップ９２６で、プリプロセッサ１１４は、いずれかの変更がステップ９２ ２で互換性のない変更と分類されていたかどうかを判断する。どの変更も互換性 のない変更と分類されていなければ、フローチャート９０２のオペレーションは ステップ９１６に示すように完了する。逆に、１つまたは２つ以上の変更が互換 性のない変更と分類されていれば、ステップ９２８が実行される。ステップ９２ ８で、プリプロセッサ１１４は再コンパイル・フラグを論理「眞」にセットする 。ステップ９２８が実行されたあと、フローチャート９０２のオペレーションは ステップ９１６に示すように完了する。 再びステップ９０８を参照するに、上述したように、選択されたヘッダ・ファ イルに対応する事前コンパイル済みヘッダ・ファイルがいくつかの事前定義の必 要条件を満足しているとプリプロセッサ１１４がステップ９０８で判断していれ ば、ステップ９１０が実行される。 ステップ９１０で、プリプロセッサ１１４は事前コンパイル済みヘッダ・ファ イルがコンパイル・ユニットが最後にコンパイルされた時刻以後に作成されたか どうかを判断する。事前コンパイル済みヘッダ・ファイルがコンパイル・ユニッ トが最後にコンパイルされた時刻以後に作成されたものであれば、コンパイル・ ユニットを再コンパイルする必要がある。そうでなければ、コンパイル・ユニッ トを再コンパイルする必要はない。 例えば、図１３に示すタイムライン１３０２の例を考えてみる。ここで、"a.h "ヘッダ・ファイル３０４がステップ８０８で選択されたものとする（図８）。 このタイムライン１３０２では、"main"ソース・ファイル２０２と"a.h"ヘッダ ・ファイル（つまり、選択されたヘッダ・ファイル）は時刻ｔ1 に作成され、時 刻ｔ２にコンパイルされている。従って、時刻ｔ２はコンパイル・ユニットが最 後にコンパイルされた時刻を表している。"a.h"ヘッダ・ファイル３０４は時刻 ｔ３に変更されている。"a.x"事前コンパイル済みヘッダ・ファイル３１４は時 刻ｔ４に再生成されている。プリプロセッサ１１４は時刻ｔ５にス テップ９１０を実行している。このタイムライン１３０２の例では、プリプロセ ッサ１１４は、"a.x"事前コンパイル済み３１４がコンパイル・ユニットが最後 にコンパイルされた時刻（時刻ｔ２）以後に作成されたものと（時刻ｔ４）ステ ップ９１０で判断することになる。 事前コンパイル済みヘッダ・ファイルがコンパイル・ユニットがコンパイルさ れた最後の時刻以後に作成されたものでないと、プリプロセッサ１１４がステッ プ９１０で判断していれば、フローチャート９０２のオペレーションはステップ ９１６に示すように完了する。逆に、事前コンパイル済みヘッダ・ファイルがコ ンパイル・ユニットがコンパイルされた最後の時刻以後に作成されたものである と、プリプロセッサ１１４が判断していれば（図１３のタイムライン１３０２に 示すように）、ステップ９１２が実行される。 ステップ９１２で、プリプロセッサ１１４はコンパイル・ユニットがコンパイ ルされた最後の時刻以後に、互換性のある変更だけが選択されたヘッダ・ファイ ルに行なわれていたかどうかを判断する。この判断は選択されたヘッダ・ファイ ルに関連する、最も最近に生成された事前コンパイル済みヘッダ・ファイルのヘ ッダ６０４を参照することによって行なわれる（図７を参照）。互換性のある変 更だけが行なわれていれば（従って、互換性のない変更が行なわれていなければ ）、コンパイル・ユニットを再コンパイルする必要はない。逆に、互換性のない 変更が行なわれていれば、コンパイル・ユニットを再コンパイルする必要がある 。 例えば、図１４に示すタイムライン１４０２の例を考えてみる。この例でも、 "a.h"ヘッダ・ファイル３０４がステップ８０８で選択されたものとする（図８ ）。このタイムライン１４０２では、"main"ソース・ファイル２０２と"a.h"ヘ ッダ・ファイル３０４（つまり、選択されたヘッダ・ファイル）は時刻ｔ1 に作 成され、時刻ｔ２にコンパイルされている。"a.h"ヘッダ・ファイル３０４は時 刻ｔ４に互換性のない変更で変更されている。"a.x"事前コンパイル済みヘッダ ・ファイル３１４″は時刻ｔ５に再生成されている。"a.h"ヘッダ・ファイル３ ０４は時刻ｔ７に互換性のある変更だけで変更され、"a.x"事前コンパイル済み ヘッダ・ファイル３１４は時刻ｔ８に再生成されている。プリプロセッサ １１４は時刻ｔ１０にステップ９１２を実行する。 ステップ９１２で行なわれる解析は、コンパイル・ユニットが最後にいつコン パイルされたかによって左右される。コンパイル・ユニットが最後に時刻ｔ３に コンパイルされていれば（または、時刻ｔ３より以前（例えば、時刻ｔ２）にコ ンパイルされていれば）、コンパイル・ユニットを再コンパイルする必要がある 。これが事実であるのはコンパイル・ユニットが最後にコンパイルされた時刻（ 時刻ｔ３）以後に１つまたは２つ以上の互換性のない変更が"a.h"ヘッダ・ファ イル３０４に行なわれている（時刻ｔ４）からである。 コンパイル・ユニットが最後に時刻ｔ６にコンパイルされていれば、コンパイ ル・ユニットを再コンパイルする必要はない。これが事実であるのは、コンパイ ル・ユニットがコンパイルされた最後の時刻（時刻ｔ６）以後に互換性のある変 更だけが"a.h"ヘッダ・ファイル３０４に行なわれている（時刻ｔ７）からであ る。 コンパイル・ユニットが最後に時刻ｔ９にコンパイルされていれば、コンパイ ル・ユニットを再コンパイルする必要がある。これが事実であるのは、"a.x"事 前コンパイル済みヘッダ・ファイル３１４が時刻ｔ８に最後に作成されており、 これは、コンパイル・ユニットが最後にコンパイルされた時刻である時刻ｔ９よ りも前であるためである。 タイムライン１０４の上記解析は、図１５に示すテーブル１５０２に要約され ている。 ステップ９１２で、コンパイル・ユニットがコンパイルされた最後の時刻以後 に互換性のある変更だけが選択されたヘッダ・ファイルに行なわれていたと、プ リプロセッサ１１４が判断していれば、フローチャート９０２のオペレーション はステップ９１６に示すように完了する。逆に、コンパイル・ユニットがコンパ イルされた最後の時刻以後に１つまたは２つ以上の互換性のない変更が選択され たヘッダ・ファイルに行なわれていたと、プリプロセッサ１１４が判断していれ ば、ステップ９１４が実行される。ステップ９１４で、プリプロセッサ１１４は 再コンパイル・フラグをセットする。ステップ９１４が実行されたあと、フロー チャート９０２のオペレーションはステップ９１６に示すように完了する。 以上、本発明の種々の実施例について説明してきたが、これらの実施例は単な る例示であり、本発明はこれらの実施例に限定されないことはもちろんである。 従って、本発明の範囲は上述した実施例のいずれによっても限定されず、以下の 請求の範囲およびその等価的事項によってのみ規定されるべきものである。

【手続補正書】 【提出日】１９９７年２月２７日 【補正内容】 (１)請求の範囲を別紙の通り補正する。 (２)明細書第２頁第２１行から同頁最終行「本発明は 〜 を判別する。」 を以下に補正する。 「本発明は、複数のソース・コード・モジュールを有するコンパイル・ユニッ トであって、ソース・コード・モジュールは非コンパイル・ユニットであり、コ ンパイル・ユニットのコンパイル時に該コンパイル・ユニットに明示的に組み込 まれている、コンパイル・ユニットと、ソース・コード・モジュールの１つとを 選択する。 次に本発明は、選択されたソース・コード・モジュールの新しい圧縮表現(new condensed representation)を生成する必要があるか否かを判断し、必要があれ ば選択されたソース・コード・モジュールの新しい圧縮表現を生成する。 そして、選択されたソース・コード・モジュールの新しい圧縮表現と選択され たソース・コード・モジュールの元の圧縮表現(old condensed representation) との間に変更があるかどうかを判別する。」 請求の範囲 １．複数のソース・コード・モジュールを有するコンパイル・ユニットを条件付 きで再コンパイルする方法であって、 （１）(i) 複数のソース・コード・モジュールを有するコンパイル・ユニット であって、該ソース・コード・モジュールは非コンパイル・ユニットであり、お よび前記コンパイル・ユニットのコンパイル時に該コンパイル・ユニットに明示 的に組み込まれているコンパイル・ユニットと、 (ii)該ソース・コード・モジュールの１つと を選択するステップと、 （２）前記選択されたソース・コード・モジュールの新しい圧縮表現を生成す る必要があるか否かを判断するステップと、 （３）前記ステップ（２）の判断を条件として該選択されたソース・コード・ モジュールの新しい圧縮表現を生成するステップと、 （４）該選択されたソース・コード・モジュールの前記新しい圧縮表現と該選 択されたソース・コード・モジュールの元の圧縮表現との間の変更を判別するス テップと、 （５）前記変更の各々を互換性のある変更と互換性のない変更のいずれかに分 類するステップであって、互換性のない変更は該コンパイル・ユニットの再コン パイルを必要とする変更であり、互換性のある変更は該コンパイル・ユニットの 再コンパイルを必要としない変更であるステップと、 （６）該変更のいずれかが互換性のない変更であると分類されたとき、該コン パイル・ユニットの再コンパイルを可能にするステップと を具えたことを特徴とする方法。 ２．請求項１に記載の方法において、 （７）前記ソース・コード・モジュールの各々について前記ステップ（１）か ら（６）までを実行するステップをさらに具えたことを特徴とする方法。 ３．請求項１に記載の方法において、前記ステップ（２）は、 前記圧縮表現が前記選択されたソース・コード・モジュールよりも古いか否か を判断するステップと、 該圧縮表現が該選択されたソース・コード・モジュールよりも古いと判断され たときに、該選択されたソース・コード・モジュールの新しい圧縮表現を生成す る必要があると判断するステップと を有することを特徴とする方法。 ４．請求項１に記載の方法において、前記ステップ（２）は、 前記選択されたソース・コード・モジュールに含まれるマクロ・ステートメン トが前記元の圧縮表現の生成時以後に変更されていたか否かを判断するステップ と、 前記マクロ・ステートメントが該元の圧縮表現の生成時以後に変更されていた と判断されたときに、該選択されたソース・コード・モジュールの新しい圧縮表 現を生成する必要があると判断するステップと を有することを特徴とする方法。 ５．請求項１に記載の方法において、前記ステップ（５）および（６）は、 前記変更のいずれかが互換性のない変更と分類されたとき、前記コンパイル・ ユニットに関連づけられた再コンパイル・フラグをあらかじめ決めた値にセット するステップと、 該コンパイル・ユニットが前記あらかじめ決めた値にセットされていれば、該 コンパイル・ユニットのコンパイルを可能にするステップと を有することを特徴とする方法。 ６．請求項１に記載の方法において、前記ステップ（１）(ii)と（２）との間に 実行されるステップであって、 前記選択されたソース・コード・モジュールのいずれかの圧縮表現が存在する か否かを判断するステップと、 該ソース・コード・モジュールの圧縮表現が存在しないと判断されたときには 、該選択されたソース・コード・モジュールの圧縮表現を生成するステップと、 前記コンパイル・ユニットのコンパイルを可能にするステップと をさらに具えたことを特徴とする方法。 ７．請求項１に記載の方法であって、前記選択されたソース・コード・モジュー ルの新しい圧縮表現を生成する必要がないと前記ステップ（２）において判断さ れたときに実行されるステップであって、 前記元の圧縮表現が前記コンパイル・ユニットがコンパイルされた最後の時刻 以後に生成されたか否かを判断するステップと、 該元の圧縮表現が該コンパイル・ユニットがコンパイルされた最後の時刻以後 に生成されたと判断されたときに、該元の圧縮表現の以前のバージョンに対して 、該元の圧縮表現の中に互換性のない変更が存在するか否かを判断するステップ と、 少なくとも１つの互換性のない変更が該元の圧縮表現の中に存在すると判断さ れたときのみ該コンパイル・ユニットのコンパイルを可能にするステップと をさらに具えたことを特徴とする方法。 ８．複数のソース・コード・モジュールを有するコンパイル・ユニットを条件付 きで再コンパイルするシステムであって、 複数のソース・コード・モジュールを有するコンパイル・ユニットを選択する コンパイル・ユニット選択手段であって、前記ソース・コード・モジュールは非 コンパイル・ユニットであり、前記コンパイル・ユニットのコンパイル時に該コ ンパイル・ユニットに明示的に組み込まれているコンパイル・ユニット選択手段 と、 前記ソース・コード・モジュールの１つを選択するモジュール選択手段と、 前記選択されたソース・コード・モジュールの新しい圧縮表現を生成する必要 があるか否かを判断するモジュール生成判断手段と、 前記モジュール生成判断手段の前記判断を条件として、該選択されたソース・ コード・モジュールの新しい圧縮表現を生成する圧縮表現生成手段と、 該選択されたソース・コード・モジュールの前記新しい圧縮表現と該選択され たソース・コード・モジュールの元の圧縮表現との間の変更を判別する変更判別 手段と、 前記変更の各々を互換性のある変更と互換性のない変更のいずれかに分類する 変更分類手段であって、互換性のない変更は前記コンパイル・ユニットの再コン パイルを必要とする変更であり、互換性のある変更は該コンパイル・ユニットの 再コンパイルを必要としない変更である変更分類手段と、 該変更のいずれかが互換性のない変更と分類されたときに、該コンパイル・ユ ニットの再コンパイルを可能にするコンパイル可能手段と を具えたことを特徴とするシステム。 ９．請求項８に記載のシステムにおいて、前記モジュール生成判断手段は、 前記元の圧縮表現が前記選択されたソース・コード・モジュールよりも古いか 否かを判断する手段と、 該元の圧縮表現が該選択されたソース・コード・モジュールよりも古いと判断 されたときに、該選択されたソース・コード・モジュールの新しい圧縮表現を生 成する必要があると判断する手段と を有することを特徴とするシステム。 １０．請求項８に記載のシステムにおいて、前記モジュール生成判断手段は、 前記選択されたソース・コード・モジュールに含まれるマクロ・ステートメン トが前記元の圧縮表現が生成された時刻以後に変更されたか否かを判断する手段 と、 前記マクロ・ステートメントが該元の圧縮表現が生成された時刻以後に変更さ れたと判断されたときに、該選択されたソース・コード・モジュールの新しい圧 縮表現を生成する必要があると判断する手段と を有することを特徴とするシステム。 １１．請求項８に記載のシステムにおいて、前記変更分類手段は、前記変更のい ずれかが互換性のない変更であると分類されたときに、前記コンパイル・ユニッ トに関連づけられた再コンパイル・フラグをあらかじめ定義した値にセットする 手段を有し、および前記コンパイル可能手段は前記再コンパイル・フラグが前記 あらかじめ定義した値にセットされたときに、該コンパイル・ユニットのコンパ イルを可能にする手段を有することを特徴とするシステム。 １２．請求項８に記載のシステムにおいて、 前記選択されたソース・コード・モジュールのいずれかの圧縮表現が存在する か否かを判断する手段と、 該選択されたソース・コード・モジュールの圧縮表現が存在しないと判断され たときに、該ソース・コード・モジュールの圧縮表現を生成する手段と、 前記コンパイル・ユニットのコンパイルを可能にする手段と をさらに具えたことを特徴とするシステム。 １３．請求項８に記載のシステムにおいて、 前記選択されたソース・コード・モジュールの新しい圧縮表現を生成する必要 がないと前記モジュール生成判断手段によって判断されたときに、前記元の圧縮 表現が前記コンパイル・ユニットがコンパイルされた最後の時刻以後に生成され たか否かを判断する手段と、 該元の圧縮表現が該コンパイル・ユニットがコンパイルされた最後の時刻以後 に生成されたと判断されたときに、該元の圧縮表現の以前のバージョンに対して 、該元の圧縮表現の中に互換性のない変更が存在するか否かを判断する手段と、 少なくとも１つの互換性のない変更が該元の圧縮表現の中に存在するときのみ 該コンパイル・ユニットのコンパイルを可能にする手段と をさらに具えたことを特徴とするシステム。 １４．複数のソース・コード・モジュールを有するコンパイル・ユニットを再コ ンパイルする必要があるか否かを判断するコンパイラ・プリプロセッサであって 、 複数のソース・コード・モジュールを有するコンパイル・ユニットを選択する コンパイル・ユニット選択手段であって、前記ソース・コード・モジュールは非 コンパイル・ユニットであり、前記コンパイル・ユニットのコンパイル時に該コ ンパイル・ユニットに明示的に組み込まれているコンパイル・ユニット選択手段 と、 前記ソース・コード・モジュールの１つを選択するモジュール選択手段と、 前記選択されたソース・コード・モジュールの新しい圧縮表現を生成する必要 があるか否かを判断するモジュール生成判断手段と、 前記モジュール生成判断手段の前記判断を条件として、該選択されたソース・ コード・モジュールの新しい圧縮表現を生成する圧縮表現生成手段と、 該選択されたソース・コード・モジュールの前記新しい圧縮表現と該選択され たソース・コード・モジュールの元の圧縮表現との間の変更を判別する変更判別 手段と、 前記変更の各々を互換性のある変更と互換性のない変更のいずれかに分類する 変更分類手段であって、互換性のない変更は前記コンパイル・ユニットの再コン パイルを必要とする変更であり、互換性のある変更は該コンパイル・ユニットの 再コンパイルを必要としない変更である変更分類手段と、 該変更のいずれかが互換性のない変更と分類されているときに、該コンパイル ・ユニットの再コンパイルを可能にするコンパイル可能手段と を具えたことを特徴とするコンパイラ・プリプロセッサ。 １５．請求項１４に記載のコンパイラ・プリプロセッサにおいて、前記モジュー ル生成判断手段は、 前記元の圧縮表現が前記選択されたソース・コード・モジュールよりも古いか 否かを判断する手段と、 該元の圧縮表現が該選択されたソース・コード・モジュールよりも古いと判断 されたとき、該選択されたソース・コード・モジュールの新しい圧縮表現を生成 する必要があると判断する手段と を有することを特徴とするコンパイラ・プリプロセッサ。 １６．請求項１４に記載のコンパイラ・プリプロセッサにおいて、前記モジュー ル生成判断手段は、 前記選択されたソース・コード・モジュールに含まれるマクロ・ステートメン トが前記元の圧縮表現が生成された時刻以後に変更されたか否かを判断する手段 と、 前記マクロ・ステートメントが該元の圧縮表現が生成された時刻以後に変更さ れたと判断されたとき、該選択されたソース・コード・モジュールの新しい圧縮 表現を生成する必要があると判断する手段と を有することを特徴とするコンパイラ・プリプロセッサ。 １７．請求項１４に記載のコンパイラ・プリプロセッサにおいて、前記変更分類 手段は、前記変更のいずれかが互換性のない変更であると分類されたとき、前記 コンパイル・ユニットに関連づけられた再コンパイル・フラグをあらかじめ定義 した値にセットする手段を有し、および前記コンパイル可能手段は前記再コンパ イル・フラグが前記あらかじめ定義した値にセットされたときに、該コンパイル ・ユニットのコンパイルを可能にする手段を有することを特徴とするコンパイラ ・プリプロセッサ。 １８．請求項１４に記載のコンパイラ・プリプロセッサにおいて、 前記選択されたソース・コード・モジュールのいずれかの圧縮表現が存在する か否かを判断する手段と、 該選択されたソース・コード・モジュールの圧縮表現が存在しないと判断され たときに、該ソース・コード・モジュールの圧縮表現を生成する手段と、 前記コンパイル・ユニットのコンパイルを可能にする手段と をさらに具えたことを特徴とするコンパイラ・プリプロセッサ。 １９．請求項１４に記載のコンパイラ・プリプロセッサにおいて、 前記選択されたソース・コード・モジュールの新しい圧縮表現を生成する必要 がないと前記モジュール生成判断手段によって判断されたときに、前記元の圧縮 表現が前記コンパイル・ユニットがコンパイルされた最後の時刻以後に生成され たか否かを判断する手段と、 該元の圧縮表現が該コンパイル・ユニットがコンパイルされた最後の時刻以後 に生成されたと判断されたときに、該元の圧縮表現の以前のバージョンに対して 、該元の圧縮表現の中に互換性のない変更が存在するか否かを判断する手段と、 少なくとも１つの互換性のない変更が該元の圧縮表現の中に存在するときのみ 該コンパイル・ユニットのコンパイルを可能にする手段と をさらに具えたことを特徴とするコンパイラ・プリプロセッサ。

Claims (1)

1. 【特許請求の範囲】 １．複数のソース・コード・モジュールを有するコンパイル・ユニットを条件付 きで再コンパイルする方法であって、 （１）前記ソース・コード・モジュールの１つを選択するステップと、 （２）前記選択されたソース・コード・モジュールの新しい圧縮表現を生成す る必要があるか否かを判断するステップと、 （３）ステップ（２）の前記判断を条件として該選択されたソース・コード・ モジュールの新しい圧縮表現を生成するステップと、 （４）該選択されたソース・コード・モジュールの前記新しい圧縮表現と該選 択されたソース・コード・モジュールの元の圧縮表現との間の変更を判別するス テップと、 （５）前記変更の各々を互換性のある変更と互換性のない変更のいずれかに分 類するステップであって、互換性のない変更は前記コンパイル・ユニットの再コ ンパイルを必要とする変更であり、互換性のある変更は該コンパイル・ユニット の再コンパイルを必要としない変更であるステップと、 （６）前記変更のいずれかが互換性のない変更と分類されたとき、該コンパイ ル・ユニットの再コンパイルを可能にするステップと を具えたことを特徴とする方法。 ２．請求項１に記載の方法において、 （７）前記ソース・コード・モジュールの各々について前記ステップ（１）か ら（６）までを実行するステップをさらに具えたことを特徴とする方法。 ３．請求項１に記載の方法において、前記ステップ（２）は、 前記圧縮表現が前記選択されたソース・コード・モジュールよりも古いか否か を判断するステップと、 該圧縮表現が該選択されたソース・コード・モジュールよりも古いと判断され たときに、該選択されたソース・コード・モジュールの新しい圧縮表現を生成す る必要があると判断するステップと を有することを特徴とする方法。 ４．請求項１に記載の方法において、前記ステップ（２）は、 前記選択されたソース・コード・モジュールに含まれるマクロ・ステートメン トが前記元の圧縮表現の生成時以後に変更されていたか否かを判断するステップ と、 前記マクロ・ステートメントが該元の圧縮表現の生成時以後に変更されていた と判断されたときに、該選択されたソース・コード・モジュールの新しい圧縮表 現を生成する必要があると判断するステップと を有することを特徴とする方法。 ５．請求項１に記載の方法において、前記ステップ（５）および（６）は、 前記変更のいずれかが互換性のない変更と分類されたとき、前記コンパイル・ ユニットに関連づけられた再コンパイル・フラグをあらかじめ決めた値にセット するステップと、 該コンパイル・ユニットが前記あらかじめ決めた値にセットされていれば、該 コンパイル・ユニットのコンパイルを可能にするステップと を有することを特徴とする方法。 ６．請求項１に記載の方法において、ステップ（１）と（２）との間に実行され るステップであって、 前記選択されたソース・コード・モジュールのいずれかの圧縮表現が存在する か否かを判断するステップと、 該選択されたソース・コード・モジュールの圧縮表現が存在しないと判断され たときに、該選択されたソース・コード・モジュールの圧縮表現を生成するステ ップと、 前記コンパイル・ユニットのコンパイルを可能にするステップと をさらに具えたことを特徴とする方法。 ７．請求項１に記載の方法であって、前記選択されたソース・コード・モジュー ルの新しい圧縮表現を生成する必要がないと前記ステップ（２）において判断さ れたときに実行されるステップであって、 前記元の圧縮表現が前記コンパイル・ユニットがコンパイルされた最後の時刻 以後に生成されたか否かを判断するステップと、 該元の圧縮表現が該コンパイル・ユニットがコンパイルされた最後の時刻以後 に生成されたと判断されたときに、該元の圧縮表現の以前のバージョンに対して 、該元の圧縮表現の中に互換性のない変更が存在するか否かを判断するステップ と、 少なくとも１つの互換性のない変更が該元の圧縮表現の中に存在すると判断さ れたときのみ該コンパイル・ユニットのコンパイルを可能にするステップと をさらに具えたことを特徴とする方法。 ８．複数のソース・コード・モジュールを有するコンパイル・ユニットを条件付 きで再コンパイルするシステムであって、 前記ソース・コード・モジュールの１つを選択するモジュール選択手段と、 前記選択されたソース・コード・モジュールの新しい圧縮表現を生成する必要 があるか否かを判断するモジュール生成判断手段と、 前記モジュール生成判断手段の前記判断を条件として、該選択されたソース・ コード・モジュールの新しい圧縮表現を生成する圧縮表現生成手段と、 該選択されたソース・コード・モジュールの前記新しい圧縮表現と該選択され たソース・コード・モジュールの元の圧縮表現との間の変更を判別する変更判別 手段と、 前記変更の各々を互換性のある変更と互換性のない変更のいずれかに分類する 変更分類手段であって、互換性のない変更は前記コンパイル・ユニットの再コン パイルを必要とする変更であり、互換性のある変更は該コンパイル・ユニットの 再コンパイルを必要としない変更である変更分類手段と、 該変更のいずれかが互換性のない変更と分類されたときに、該コンパイル・ユ ニットの再コンパイルを可能にするコンパイル可能手段と を具えたことを特徴とするシステム。 ９．請求項８に記載のシステムにおいて、前記モジュール生成判断手段は、 前記元の圧縮表現が前記選択されたソース・コード・モジュールよりも古いか 否かを判断する手段と、 該元の圧縮表現が該選択されたソース・コード・モジュールよりも古いと判断 されたときに、該選択されたソース・コード・モジュールの新しい圧縮表現を生 成する必要があると判断する手段と を有することを特徴とするシステム。 １０．請求項８に記載のシステムにおいて、前記モジュール生成判断手段は、 前記選択されたソース・コード・モジュールに含まれるマクロ・ステートメン トが前記元の圧縮表現が生成された時刻以後に変更されたか否かを判断する手段 と、 前記マクロ・ステートメントが該元の圧縮表現が生成された時刻以後に変更さ れたと判断されたときに、該選択されたソース・コード・モジュールの新しい圧 縮表現を生成する必要があると判断する手段と を有することを特徴とするシステム。 １１．請求項８に記載のシステムにおいて、前記変更分類手段は、前記変更のい ずれかが互換性のない変更であると分類されたときに、前記コンパイル・ユニッ トに関連づけられた再コンパイル・フラグをあらかじめ定義した値にセットする 手段を有し、および前記コンパイル可能手段は前記再コンパイル・フラグが前記 あらかじめ定義した値にセットされたときに、該コンパイル・ユニットのコンパ イルを可能にする手段を有することを特徴とするシステム。 １２．請求項８に記載のシステムにおいて、 前記選択されたソース・コード・モジュールのいずれかの圧縮表現が存在する か否かを判断する手段と、 該選択されたソース・コード・モジュールの圧縮表現が存在しないと判断され たときに、該ソース・コード・モジュールの圧縮表現を生成する手段と、 前記コンパイル・ユニットのコンパイルを可能にする手段と をさらに具えたことを特徴とするシステム。 １３．請求項８に記載のシステムにおいて、 前記選択されたソース・コード・モジュールの新しい圧縮表現を生成する必要 がないと前記モジュール生成判断手段によって判断されたときに、前記元の圧縮 表現が前記コンパイル・ユニットがコンパイルされた最後の時刻以後に生成され たか否かを判断する手段と、 該元の圧縮表現が該コンパイル・ユニットがコンパイルされた最後の時刻以後 に生成されたと判断されたときに、該元の圧縮表現の以前のバージョンに対して 、該元の圧縮表現の中に互換性のない変更が存在するか否かを判断する手段と、 少なくとも１つの互換性のない変更が該元の圧縮表現の中に存在するときのみ 該コンパイル・ユニットのコンパイルを可能にする手段と をさらに具えたことを特徴とするシステム。 １４．複数のソース・コード・モジュールを有するコンパイル・ユニットを再コ ンパイルする必要があるか否かを判断するコンパイラ・プリプロセッサであって 、 前記ソース・コード・モジュールの１つを選択するモジュール選択手段と、 前記選択されたソース・コード・モジュールの新しい圧縮表現を生成する必要 があるか否かを判断するモジュール生成判断手段と、 前記モジュール生成判断手段の前記判断を条件として、該選択されたソース・ コード・モジュールの新しい圧縮表現を生成する圧縮表現生成手段と、 該選択されたソース・コード・モジュールの前記新しい圧縮表現と該選択され たソース・コード・モジュールの元の圧縮表現との間の変更を判別する変更判別 手段と、 前記変更の各々を互換性のある変更と互換性のない変更のいずれかに分類する 変更分類手段であって、互換性のない変更は前記コンパイル・ユニットの再コン パイルを必要とする変更であり、互換性のある変更は該コンパイル・ユニットの 再コンパイルを必要としない変更である変更分類手段と、 該変更のいずれかが互換性のない変更と分類されているときに、該コンパイル ・ユニットの再コンパイルを可能にするコンパイル可能手段と を具えたことを特徴とするコンパイラ・プリプロセッサ。 １５．請求項１４に記載のコンパイラ・プリプロセッサにおいて、前記モジュー ル生成判断手段は、 前記元の圧縮表現が前記選択されたソース・コード・モジュールよりも古いか 否かを判断する手段と、 該元の圧縮表現が該選択されたソース・コード・モジュールよりも古いと判断 されたとき、該選択されたソース・コード・モジュールの新しい圧縮表現を生成 する必要があると判断する手段と を有することを特徴とするコンパイラ・プリプロセッサ。 １６．請求項１４に記載のコンパイラ・プリプロセッサにおいて、前記モジュー ル生成判断手段は、 前記選択されたソース・コード・モジュールに含まれるマクロ・ステートメン トが前記元の圧縮表現が生成された時刻以後に変更されたか否かを判断する手段 と、 前記マクロ・ステートメントが該元の圧縮表現が生成された時刻以後に変更さ れたと判断されたとき、該選択されたソース・コード・モジュールの新しい圧縮 表現を生成する必要があると判断する手段と を有することを特徴とするコンパイラ・プリプロセッサ。 １７．請求項１４に記載のコンパイラ・プリプロセッサにおいて、前記変更分類 手段は、前記変更のいずれかが互換性のない変更であると分類されたとき、前記 コンパイル・ユニットに関連づけられた再コンパイル・フラグをあらかじめ定義 した値にセットする手段を有し、および前記コンパイル可能手段は前記再コンパ イル・フラグが前記あらかじめ定義した値にセットされたときに、該コンパイル ・ユニットのコンパイルを可能にする手段を有することを特徴とするコンパイラ ・プリプロセッサ。 １８．請求項１４に記載のコンパイラ・プリプロセッサにおいて、 前記選択されたソース・コード・モジュールのいずれかの圧縮表現が存在する か否かを判断する手段と、 該選択されたソース・コード・モジュールの圧縮表現が存在しないと判断され たときに、該ソース・コード・モジュールの圧縮表現を生成する手段と、 前記コンパイル・ユニットのコンパイルを可能にする手段と をさらに具えたことを特徴とするコンパイラ・プリプロセッサ。 １９．請求項１４に記載のコンパイラ・プリプロセッサにおいて、 前記選択されたソース・コード・モジュールの新しい圧縮表現を生成する必要 がないと前記モジュール生成判断手段によって判断されたときに、前記元の圧縮 表現が前記コンパイル・ユニットがコンパイルされた最後の時刻以後に生成され たか否かを判断する手段と、 該元の圧縮表現が該コンパイル・ユニットがコンパイルされた最後の時刻以後 に生成されたと判断されたときに、該元の圧縮表現の以前のバージョンに対して 、該元の圧縮表現の中に互換性のない変更が存在するか否かを判断する手段と、 少なくとも１つの互換性のない変更が該元の圧縮表現の中に存在するときのみ 該コンパイル・ユニットのコンパイルを可能にする手段と をさらに具えたことを特徴とするコンパイラ・プリプロセッサ。