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

Description

発明の分野
本発明は、一般的にはコンパイル・ユニット（単位）をコンパイルすることに関し、より具体的には、コンパイル・ユニットのコンポーネントが互換性のない形で変更されたときのみコンパイル・ユニットを再コンパイルすることに関する。
関連技術
ソフトウェア・コンパイル・ユニットは、「メイン」ソフトウェア・プログラムと１つまたは２つ以上のヘッダ・ファイルを含んでいるのが代表的である。ヘッダ・ファイルは「メイン」プログラムに置かれている（またはヘッダ・ファイル自体に置かれている）該当のソフトウェア・ステートメントを使用して明示的にコンパイル・ユニットの中に組み込まれている。例えば、周知のＣコンピュータ・プログラミング言語では、ヘッダ・ファイルをコンパイル・ユニットに組み込むために「インクルード（"include"）」ステートメントが使用されている。例えば、次のステートメントは、
#include "a.h"
"a.h"と名付けたヘッダ・ファイルをコンパイル・ユニットに組み入れるために「メイン」プログラムの中に挿入されている。これらはインクルード・ステートメントを使用してコンパイル・ユニットに挿入されるので、ヘッダ・ファイルは「インクルード・ファイル（include file）」とも呼ばれている。なお、本明細書では、これらの用語（つまり、「ヘッダ・ファイル」と「インクルード・ファイル」）は同じ意味をもつものとして使用されている。
従来は、「メイン」プログラムはコンパイル・ユニットがコンパイルされると、常にそのヘッダ・ファイルのすべてと一緒にコンパイルされている。周知のＵＮＩＸシステムでは、そのコンポーネント部分のいずれかが（つまり、「メイン」プログラムおよび／またはヘッダ・ファイルのいずれか）が変更されたときだけ、"make"ユーティリティがコンパイル・ユニットをコンパイルするように動作している。
しかるに、そのコンポーネント部分の１つまたは２つ以上が、コンパイル・ユニットがコンパイルされた最後の時刻以後に変更されなかった場合でも、コンパイル・ユニットを再コンパイルしないで済むことがよくある。例えば、コンパイル・ユニットのコンポーネントのフォーマットだけが変更された場合は、コンパイル・ユニットを再コンパイルする必要はない。しかし、従来は、そのコンポーネント部分になんらかの変更が行なわれると、常にコンパイル・ユニットが再コンパイルされている。従って、従来のコンパイラは不要なコンパイル・オペレーションを行なっていた。その結果、従来のコンパイラによるシステム資源の利用は非効率的であった。
発明の概要
要約して説明すると、本発明は、複数のソース・コード・モジュールからなるコンパイル・ユニット(compilation unit)を条件付きでコンピュータシステムに再コンパイル(conditional recompilation)させるコンパイラを利用するシステムおよび方法を目的としている。本発明はコンパイラによって、ソース・コード・モジュールの１つを選択し、選択されたソース・コード・モジュールの新しい圧縮表現(new condensed representation)を生成する必要があるかどうか判断することによって動作する。次に、本発明はコンパイラによって、必要があれば選択されたソース・コード・モジュールの新しい圧縮表現を生成する。そして、本発明はコンパイラによって、選択されたソース・コード・モジュールの新しい圧縮表現と選択されたソース・コード・モジュールの元の圧縮表現（old condensed representation）との間に変更があるかどうかを判別する。これらの変更の各々は、互換性のある変更(compatible change)または互換性のない変更(incompatible change)のどちらかに分類される。互換性のない変更とは、コンパイル・ユニットの再コンパイルを必要とする変更である。互換性のある変更とは、コンパイル・ユニットの再コンパイルを必要としない変更である。本発明によれば、コンパイル・ユニットの再コンパイルは、変更のいずれかが互換性のない変更であると分類されたときだけ行なわれる。
本発明のその他の特徴および利点は、本発明の種々実施例のオペレーションおよび構造と共に、添付図面を参照して以下で詳しく説明する。なお、添付図面において、同一または機能的に類似のエレメントは類似の参照符号を付けて示されている。
【図面の簡単な説明】
以下、添付図面を参照して本発明を説明する。図面において、
図１は本発明の好適実施例によるコンピュータ・システムを示すブロック図である。
図２、図３Ａ〜図３Ｃ、および図４〜図７は、図１のコンピュータ・システムの記憶デバイスにストアできるファイルのタイプと、そのようなファイルの好ましいフォーマットを示す図である。
図８〜図１０は本発明の好ましいオペレーションを示すフローチャートである。
図１１〜図１４は本発明のオペレーションを説明するために使用されるタイムラインである。
図１５は図１４に示すタイムラインに関する解析の要約テーブルである。
好適実施例の詳細な説明
図１は本発明の好適実施例によるコンピュータ・システム１０２を示すブロック図である。好ましくは、コンピュータ・システム１０２は、シリコン・グラフィックス(Silicon Graphics)社(Mountain View, CA)製のIrix 5.2オペレーティング・システムが稼働しているインディ・ワークステーション(Indy Workstation)が使用されているが、これとは別に、他の適当なコンピュータ・システムを使用することも可能である。コンピュータ・システム１０２はバス１０６に接続されたプロセッサ１０４を搭載している。好ましくは、プロセッサ１０４はSilicon Graphics社製のMIPS R4000シリーズＣＰＵであるが、これとは別に、他の適当なＣＰＵを使用することも可能である。
バス１０６には記憶デバイス１０８も接続されており、これはランダムアクセスメモリ（random access memory - ＲＡＭ）、リードオンリメモリ（read only memory - ＲＯＭ）、二次記憶デバイス（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"ヘッダ・ファイル３０４に組み込むように働く。以上から理解されるように、ヘッダ・ファイル１２０がソース・コード・モジュールを表わしているのは、これらがソース・コード（例えば、バイナリ・コードではなく）を含んでいるからである。
再び図１を参照するに、記憶デバイス１０８には、事前コンパイル済み(precompiled)ヘッダ・ファイル１２２もストアされている。この分野の当業者ならば理解されるように、事前コンパイル済みヘッダ・ファイルはヘッダ・ファイルの圧縮バイナリ表現(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)を収めている。このヘッダ・ファイル６０４については、以下で詳しく説明する。
再び図１を参照するに、記憶デバイス１０８には、オブジェクト・ファイル(object file)もストアされている。オブジェクト・ファイルはマシン命令（機械語命令）が集まったものである。１つまたは２つ以上のオブジェクト・ファイルが１つにリンクされて、実行可能プログラムが作られる。図３Ａに示すように、このようなオブジェクト・ファイル１１８は、「メイン」オブジェクト・ファイル３０２（図３では、"main.o"と名付けている）を含んでおり、これは「メイン」ソース・ファイル２０２とそのヘッダ・ファイルのコンパイル済みバイナリ・バージョンである。
本発明の好適実施例によれば、コンパイラ・プリプロセッサ１１４とソフトウェア・コンパイラ１１２はコンパイル・ユニットをコンパイルして、コンパイル・ユニットのコンパイル済みオブジェクト・コード・バージョン（つまり、オブジェクト・ファイル）を生成するように動作する。ついで、ソフトウェア・リンカ（図示せず）を使用すると、公知のように、コンパイル・ユニットのオブジェクト・コード・バージョンから実行可能ファイル(executable file)を生成することができる。なお、このソフトウェア・リンカは本発明の部ではないので、ここで詳しく説明することは省略する。実行可能ファイルは、図１に示すコンピュータ・システム１０２のように、コンピュータ・システムによって実行される。
以下では、コンパイラ・プリプロセッサ１１４とソフトウェア・コンパイラ１１２のオペレーションの概要について説明する。なお、説明の便宜上、コンパイルされるコンパイル・ユニットは、次のようなソフトウェア・エレメント(software 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"ヘッダ・ファイル３０６）は時刻ｔ１に作成されている。対応する事前コンパイル済みヘッダ・ファイル（"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"ヘッダ・ファイル（つまり、選択されたヘッダ・ファイル）は時刻ｔ１に作成され、時刻ｔ２にコンパイルされている。従って、時刻ｔ２はコンパイル・ユニットが最後にコンパイルされた時刻を表している。"a.h"ヘッダ・ファイル３０４は時刻ｔ３に変更されている。"a.x"事前コンパイル済みヘッダ・ファイル３１４は時刻ｔ４に再生成されている。プリプロセッサ１１４は時刻ｔ５にステップ９１０を実行している。このタイムライン１３０２の例では、プリプロセッサ１１４は、"a.x"事前コンパイル済み３１４がコンパイル・ユニットが最後にコンパイルされた時刻（時刻ｔ２）以後に作成されたものと（時刻ｔ４）ステップ９１０で判断することになる。
事前コンパイル済みヘッダ・ファイルがコンパイル・ユニットがコンパイルされた最後の時刻以後に作成されたものでないと、プリプロセッサ１１４がステップ９１０で判断していれば、フローチャート９０２のオペレーションはステップ９１６に示すように完了する。逆に、事前コンパイル済みヘッダ・ファイルがコンパイル・ユニットがコンパイルされた最後の時刻以後に作成されたものであると、プリプロセッサ１１４が判断していれば（図１３のタイムライン１３０２に示すように）、ステップ９１２が実行される。
ステップ９１２で、プリプロセッサ１１４はコンパイル・ユニットがコンパイルされた最後の時刻以後に、互換性のある変更だけが選択されたヘッダ・ファイルに行なわれていたかどうかを判断する。この判断は選択されたヘッダ・ファイルに関連する、最も最近に生成された事前コンパイル済みヘッダ・ファイルのヘッダ６０４を参照することによって行なわれる（図７を参照）。互換性のある変更だけが行なわれていれば（従って、互換性のない変更が行なわれていなければ）、コンパイル・ユニットを再コンパイルする必要はない。逆に、互換性のない変更が行なわれていれば、コンパイル・ユニットを再コンパイルする必要がある。
例えば、図１４に示すタイムライン１４０２の例を考えてみる。この例でも、"a.h"ヘッダ・ファイル３０４がステップ８０８で選択されたものとする（図８）。このタイムライン１４０２では、"main"ソース・ファイル２０２と"a.h"ヘッダ・ファイル３０４（つまり、選択されたヘッダ・ファイル）は時刻ｔ１に作成され、時刻ｔ２にコンパイルされている。"a.h"ヘッダ・ファイル３０４は時刻ｔ４に互換性のない変更で変更されている。"a.x"事前コンパイル済みヘッダ・ファイル３１４″は時刻ｔ５に再生成されている。"a.h"ヘッダ・ファイル３０４は時刻ｔ７に互換性のある変更だけで変更され、"a.x"事前コンパイル済みヘッダ・ファイル３１４は時刻ｔ８に再生成されている。プリプロセッサ１１４は時刻ｔ１０にステップ９１２を実行する。
ステップ９１２で行なわれる解析は、コンパイル・ユニットが最後にいっコンパイルされたかによって左右される。コンパイル・ユニットが最後に時刻ｔ３にコンパイルされていれぱ（または、時刻ｔ３より以前（例えば、時刻ｔ２）にコンパイルされていれぱ）、コンパイル・ユニットを再コンパイルする必要がある。これが事実であるのはコンパイル・ユニットが最後にコンパイルされた時刻（時刻ｔ３）以後に１つまたは２つ以上の互換性のない変更が"a.h"ヘッダ・ファイル３０４に行なわれている（時刻ｔ４）からである。
コンパイル・ユニットが最後に時刻ｔ６にコンパイルされていれば、コンパイル・ユニットを再コンパイルする必要はない。これが事実であるのは、コンパイル・ユニットがコンパイルされた最後の時刻（時刻ｔ６）以後に互換性のある変更だけが"a.h"ヘッダ・ファイル３０４に行なわれている（時刻ｔ７）からである。
コンパイル・ユニットが最後に時刻ｔ９にコンパイルされていれぱ、コンパイル・ユニットを再コンパイルする必要がある。これが事実であるのは、"a.x"事前コンパイル済みヘッダ・ファイル３１４が時刻ｔ８に最後に作成されており、これは、コンパイル・ユニットが最後にコンパイルされた時刻である時刻ｔ９よりも前であるためである。
タイムライン１４０２の上記解析は、図１５に示すテーブル１５０２に要約されている。
ステップ９１２で、コンパイル・ユニットがコンパイルされた最後の時刻以後に互換性のある変更だけが選択されたヘッダ・ファイルに行なわれていたと、プリプロセッサ１１４が判断していれば、フローチャート９０２のオペレーションはステップ９１６に示すように完了する。逆に、コンパイル・ユニットがコンパイルされた最後の時刻以後に１つまたは２つ以上の互換性のない変更が選択されたヘッダ・ファイルに行なわれていたと、プリプロセッサ１１４が判断していれば、ステップ９１４が実行される。ステップ９１４で、プリプロセッサ１１４は再コンパイル・フラグをセットする。ステップ９１４が実行されたあと、フローチャート９０２のオペレーションはステップ９１６に示すように完了する。
以上、本発明の種々の実施例について説明してきたが、これらの実施例は単なる例示であり、本発明はこれらの実施例に限定されないことはもちろんである。従って、本発明の範囲は上述した実施例のいずれによっても限定されず、以下の請求の範囲およびその等価的事項によってのみ規定されるべきものである。

Claims (13)

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

Images