B.2.124 -xpch=v

このコンパイラオプションは、プリコンパイル済みヘッダー機能を起動します。v には、auto、autofirst、collect:pch_filename、use:pch_filename のいずれかを指定できます。この機能は、-xpch (「B.2.124 -xpch=v」で詳述) と -xpchstop (「B.2.125 -xpchstop=[<ファイル>|<include>]」で詳述) オプションで、#pragma hdrstop 指令 (「2.8.8 hdrstop」で詳述) と組み合わせて利用できます。

-xpch オプションは、プリコンパイル済みヘッダーファイルを作成して、コンパイル時間を短縮するときに使用します。プリコンパイル済みヘッダーファイルは、ソースファイルが大量のソースコードを含む共通のインクルードファイル群を共有しているようなアプリケーションのコンパイル時間を低減するよう設計されています。プリコンパイル済みヘッダーを使用することによって、1 つのソースファイルから一連のヘッダーファイルに関する情報を収集し、そのソースファイルを再コンパイルする場合や、同じ一連のヘッダーを持つほかのソースファイルをコンパイルする場合に、その情報を使用することができます。コンパイラが収集する情報は、プリコンパイル済みヘッダーファイルに格納されます。

関連項目

• 「B.2.125 -xpchstop=[<ファイル>|<include>]」

• 「2.8.8 hdrstop」

B.2.124.1 プリコンパイル済みヘッダーファイルの自動作成

プリコンパイル済みヘッダーファイルをコンパイラに自動的に生成させることができます。このためには、次のいずれかの方法を選択します。1 つは、ソースファイルで検出された最初のインクルードファイルからプリコンパイル済みヘッダーファイルを作成する方法、もう 1 つは、最初のインクルードファイルから、最後のインクルードファイルを特定する綿密に定義された地点までの間にソースファイルで検出されたインクルードファイル群から選択してプリコンパイル済みヘッダーファイルを作成する方法です。次の 2 つのフラグのいずれかを使用して、プリコンパイル済みヘッダーの自動生成にコンパイラが使用すべき方法を指示します。

B.2.124.2 プリコンパイル済みヘッダーファイルの手動作成

プリコンパイル済みヘッダーファイルを手動で作成する場合は、最初に -xpch を指定し、collect モードを指定します。-xpch=collect を指定するコンパイルコマンドは、ソースファイルを 1 つしか指定できません。次の例では、-xpch オプションがソースファイル a.c に基づいて myheader.cpch というプリコンパイル済みヘッダーファイルを作成します。

cc -xpch=collect:myheader a.c

有効なプリコンパイル済みヘッダーファイル名には必ず、.cpch という接尾辞が付きます。pch_filename を指定する場合、自分で接尾辞を追加することも、コンパイラに追加させることもできます。たとえば、cc -xpch=collect:foo a.c と指定すると、プリコンパイル済みヘッダーファイルには foo.cpch という名前が付けられます。

B.2.124.3 既存のプリコンパイル済みヘッダーファイルの処理方法

-xpch=auto または -xpch=autofirst のときにプリコンパイル済みヘッダーファイルを使用できない場合、コンパイラは新しいプリコンパイル済みヘッダーファイルを生成します。-xpch=use のときにプリコンパイル済みヘッダーファイルを使用できない場合は、警告が発行され、実際のヘッダーを使ってコンパイルが行われます。

B.2.124.4 特定のプリコンパイル済みヘッダーファイルの使用の指定

特定のプリコンパイル済みヘッダーファイルを使用するようコンパイラに指示することもできます。このためには、-xpch=use:pch_filename を使用します。同じインクルードファイルのシーケンスを持つソースファイルは、プリコンパイル済みヘッダーファイルを作成するために使用されたソースファイルとして、いくつでも指定できます。たとえば、use モードで、次のようなコマンドがあるとします。cc -xpch=use:foo.cpch foo.c bar.c foobar.c.

次の項目が真の場合にかぎり、既存のプリコンパイル済みヘッダーファイルを使用します。次の項目で真ではないものがあれば、プリコンパイル済みヘッダーファイルを再作成する必要があります。

• プリコンパイル済みヘッダーファイルにアクセスするために使用するコンパイラは、プリコンパイル済みヘッダーファイルを作成したコンパイラと同じであること。あるバージョンのコンパイラで作成されたプリコンパイル済みヘッダーファイルは、別のバージョンのコンパイラでは使用できない場合があります。

• -xpch オプション以外で -xpch=use とともに指定するコンパイラオプションは、プリコンパイル済みヘッダーファイルが作成されたときに指定されたオプションと一致すること。

• -xpch=use で指定する一連のインクルードヘッダー群は、プリコンパイル済み ヘッダーファイルが作成されたときに指定されたヘッダー群と同じであること。

• -xpch=use で指定するインクルードヘッダーの内容が、プリコンパイル済みヘッ ダーファイルが作成されたときに指定されたインクルードヘッダーの内容と同じであること。

• 現在のディレクトリ (すなわち、コンパイルが実行中で指定されたプリコンパイル済みヘッダーファイルを使用しようとしているディレクトリ) が、プリコンパイル済みヘッダーファイルが作成されたディレクトリと同じであること。

• -xpch=collect で指定したファイル内の #include 指令を含む前処理指令の最初のシーケンスが、-xpch=use で指定するファイル内の前処理指令のシーケンスと同じであること。

B.2.124.5 活性文字列 (Viable Prefix)

複数のソースファイル間でプリコンパイル済みヘッダーファイルを共有するために は、そのようなソースファイルは、一連の同じインクルードファイルがトークンの最初の並びとして記述されている必要があります。トークンはキーワードか名前、句読点のいずれかです。コンパイラは、コードおよび、#if 指令によって除外されたコードをトークンとして認識しません。トークンのこの最初の並びは、活性文字列 (viable prefix) といいます。言い替えれば、活性文字列は、すべてのソースファイルに共通のソースファイルの先頭部分です。コンパイラは、この活性文字列に基づいて、プリコンパイル済みヘッダーファイルを作成し、ソース内のプリコンパイルするヘッダーファイルを特定します。

現在のコンパイル中にコンパイラが検出する活性文字列は、プリコンパイル済みヘッダーファイルの作成に使用した活性文字列と一致する必要があります。言い替えれば、活性文字列は、同じプリコンパイル済みヘッダーファイルを使用するすべてのソースファイル間で一貫して解釈される必要があります。

ソースファイルの活性文字列には、コメントと次に示すプリプロセッサ指令のみを指定できます。

#include
#if/ifdef/ifndef/else/elif/endif
#define/undef
#ident (if identical, passed through as is)
#pragma (if identical)

前述の任意の指令はマクロを参照する場合があります。#else、#elif、#endif 指令は、活性文字列内で一致している必要があります。コメントは無視されます。

-xpch=auto か -xpch=autofirst が指定されていて、次のように定義されている場合、コンパイラは活性文字列の終点を自動的に特定します。-xpch=collect または -xpch=use の場合、活性文字列は #pragma hdrstop で終了します。

• 最初の宣言/定義文

• 最初の #line 指令

• #pragma hdrstop 指令

• 指定されたインクルードファイルのあと (-xpch=auto および -xpchstop が指定された場合)

• 最初のインクルードファイル ( -xpch=autofirst が指定された場合)

  ---

  注 –

  条件文内に終点がある場合は、警告が生成され、プリコンパイル済みヘッダーファイルの自動作成は無効になります。また、#pragma hdrstop と -xpchstop オプションの両方が指定された場合、コンパイラは 2 つの停止点のうちの早い方を使用して、活性文字列を終了します。

  ---

プリコンパイル済みヘッダーファイルを共有する各ファイルの活性文字列内では、対応する各 #define 指令と #undef 指令は同じシンボルを参照する必要があります (#define の場合は、各指令は同じ値を参照しなければいけません)。各活性文字列内での順序も同じである必要があります。対応する各プラグマも同じで、その順序もプリコンパイル済みヘッダーを共有するすべてのファイルで同じでなければいけません。

B.2.124.6 ヘッダーファイルの妥当性の判定

ヘッダーファイルがプリコンパイル可能となる条件。それは、複数のソースファイルに渡ってヘッダーファイルの一貫した解釈ができることです。具体的には、完全な宣言だけが含まれていることです。すなわち、どのファイルの宣言も有効な宣言として独立している必要があります。struct S; などの不完全な型宣言は有効な型宣言です。完全な型宣言がほかのファイルに存在している可能性があります。次のヘッダーファイルの例を考えてみてください。

file a.h
struct S {
#include "x.h" /* 許されない */
};

file b.h
struct T; // ok、完全な宣言
struct S {
   int i;
[ファイルの終わり、別のファイルに続く] /* 許されない*/

プリコンパイル済みヘッダーファイルに組み込まれるヘッダーファイルは、次の項目に違反しないようにしてください。これらの制限に違反するプログラムをコンパイルした場合、結果は予測できません。

• ヘッダーファイルに、__DATE__ や __TIME__ が含まれていてはならない。

• ヘッダーファイルに、#pragma hdrstopが含まれていてはならない。

B.2.124.7 プリコンパイル済みヘッダーファイルのキャッシュ

プリコンパイル済みヘッダーファイルの自動作成では、コンパイラは、そのファイルを SunWS_cache ディレクトリに書き込みます。このディレクトリは常に、オブジェクトファイルが作成される場所に置かれます。dmake の下で適切に機能するように、ファイルの更新はロックして行われます。

強制的に再構築させる必要がある場合は、CCadmin ツールを使って、このプリコンパイル済みヘッダーファイルのキャッシュディレクトリをクリアすることができます。詳細は、CCadmin(1) のマニュアルページを参照してください。

B.2.124.8 警告

• 矛盾する -xpch フラグをコマンド行に指定しないでください。たとえば、-xpch=collect と -xpch=auto の両方を指定したり、-xpchstop=<include> を付けて -xpch=autofirst を指定したりすると、エラーになります。

• -xpch=autofirst を指定するか、-xpchstop なしで -xpch=auto を指定した場合、最初のインクルードファイル、あるいは -xpch=auto に -xpchstop を付けて指定したインクルードファイルの前に宣言や定義、#line 指令があると、エラーになり、プリコンパイル済みヘッダーファイルの自動生成が無効になります。

• -xpch=autofirst または -xpch=auto で、最初のインクルードファイルの前に #pragma hdrstop があると、プリコンパイル済みヘッダーファイルの自動生成が無効になります。

B.2.124.9 プリコンパイル済みヘッダーファイルの依存関係と make ファイル

-xpch=collect が指定されている場合、コンパイラはプリコンパイル済みヘッダーファイル用の依存関係情報を生成します。この依存関係情報を利用するには、メイクファイル内に適切な規則を作成する必要があります。次のメイクファイルの例を考えてみてください。

%.o : %.c shared.cpch
         $(CC) -xpch=use:shared -xpchstop=foo.h -c $<
default : a.out

foo.o + shared.cpch : foo.c
         $(CC) -xpch=collect:shared -xpchstop=foo.h foo.c -c

a.out : foo.o bar.o foobar.o
         $(CC) foo.o bar.o foobar.o

clean :
         rm -f *.o shared.cpch .make.state a.out

コンパイラによって生成された依存関係情報とともに、これらの make 規則があると、-xpch=collect で使用されたソースファイル、またはプリコンパイル済みヘッダーファイルを構成するヘッダーのどれかに変更があった場合、手動で作成されたプリコンパイル済みヘッダーファイルが強制的に再作成されます。これにより、古いプリコンパイル済みヘッダーファイルの使用が防止されます。

-xpch=auto または -xpch=autofirst の場合、メイクファイルに追加の make 規則を作成する必要はありません。