Imagix 4D ソースアナライザがソースコードを処理する際は、コンパイラと同様の方法でヘッダファイルを取り扱います。C / C++ ソースファイルは、直接、プロジェクト設定で明示的に指定することにより解析されますが、その一方でヘッダファイルは、ソースファイルに #include 文が記述されている場合に限り、解析されます。

Imagix 4D ソースアナライザが #include ディレクティブを認識すると、ここでもコンパイラと同じ方法で適切なヘッダファイルを検索します。まず、ローカルディレクトリを確認し、次にプロジェクト設定で指定されている、その他のインクルード・ディレクトリを検索します。ソースアナライザが適切なヘッダファイルを検出できない場合には、次のフォーマットでエラーメッセージを出力します。

Analyzing c:/dev/project/vers-r1/power.c
   c:/dev/project/vers-r1/assist.h, 24: error - cannot open "drive/understeer.h"

この点においてソースアナライザは、多くのコンパイラとは異なり、オリジナルのソースコードの解析を継続します。しかし、ソースアナライザにはエラー訂正機能が標準搭載されているものの、ヘッダファイルの検出と解析に失敗すると次のような影響を及ぼします。ソースファイルのダウンストリーム・コードの意味解析において、ヘッダファイルにクラス、型、その他の定義が欠如していることを受け、警告やエラーを生成するのです。

検出された不明なヘッダファイルが、より精確なプロジェクト・データベースとなるよう、インクルード・ディレクトリを正しく指定するためにプロジェクト・セットアップを修正します。

不明なヘッダファイルの解決は、エラーメッセージのレビューとプロジェクト設定の修正からなり、一般的に次の順序で行います。

不明なヘッダは、アプリケーション・ヘッダファイルもしくはシステム・ヘッダファイルのどちらなのか？

Imagix 4D はヘッダファイルの領域、つまりソースコードのヘッダファイルの一部と、stdio.h のようなコンパイラあるいはオペレーティング・システム環境のヘッダファイルの一部を、区別します。一般的に、アプリケーション・ヘッダファイルのコンテンツの理解に対しては関心が向けられますが、これに比べシステム・ヘッダファイルに関心を示す人はあまり見受けられません。このため、コードを意味的に解析するためには双方の設定が求められますが、Imagix 4D のデフォルト設定では、作成されるデータベースにシステム・ヘッダファイルに関する情報を格納しないよう動作します。

体系化や効率化を目的としたシステム・ヘッダファイル用のインクルード・ディレクトリは、多くの場合において、拡張子 .inc のコンパイラ設定ファイルで指定されます。一方でアプリケーション自体のヘッダファイルの格納場所は、プロジェクトに固有の設定の一部として指定します。サードパーティ製ライブラリのヘッダファイルは、いずれかの設定としてグループ化される可能性があり、これはプロジェクト全体にわたりそれらのファイルを使用する度合や、どの程度そのコンテンツに関心を持っているのかに依存します。

不明なヘッダを解決する最初のステップは、エラーメッセージをレビューすることです。エラーメッセージは、Imagix 4D のメインディスプレイにある [解析結果] タブに表示されます。この作業に伴いプロジェクト設定を部分的に微調整する際には、タブのローカルメニューにある [表示] > [ファイルエラーメッセージを表示] を設定する必要が生じることがあります。

以下に [解析結果] メッセージの例をあげます。

Analyzing c:/dev/project/vers-r1/power.c
   c:/dev/project/vers-r1/assist.h, 24: error - cannot open "drive/understeer.h"

このメッセージには、ソースファイル power.c の解析中に、問題が発生したことが示されています。直接的あるいは間接的に、power.c は assist.h をインクルードしました。同様に assist.h は（24行目で）、understeer.h のインクルードを試みましたが、understeer.h を検出できなかったためエラーメッセージが生成されたのです。

不明なヘッダファイルの名前か、#include ディレクティブが記述されたファイルの名前かによって異なりますが、このエラーメッセージが、不明なファイルがアプリケーション・ヘッダファイルなのか、システム・ヘッダファイルなのかを判断する材料となる可能性があります。もしくは、まだ、判断することが難しいかもしれません。いずれにせよ最終的には、不明なヘッダの解決に、その情報が必要となります。

各環境におけるヘッダファイルの格納場所はどこなのか？

不明なファイルが、アプリケーション・ヘッダファイルなのか、システム・ヘッダファイルなのかが判明している場合には、不明なファイルを検索する場所をより正確に絞り込めます。いずれのファイルなのか判断がつかなければ、さらに広範囲にわたり調査する必要があります。しかし、どちらの場合においても、不明なヘッダファイルが格納されている適切なディレクトリを特定する必要があるのです。

ヘッダファイルを突き止めることで、ヘッダファイルのタイプを、より確実に把握できます。

しかしながら、不明なヘッダファイルの検索が順調に進まないケースもあります。正しい名前のヘッダファイルを見つけることが、できないかもしれません。また仮に発見したとしても、パスが誤っている可能性もあるのです。例えば、前述のエラーメッセージから、インクルード・ディレクティブが #include "drive/understeer.h" であったことが分かります。このため、understeer.h は drive という名前のディレクトリに保存されなければいけません。つまり、drive 以外のディレクトリに understeer.h のインスタンスが存在する場合は、#include ディレクティブの指定に一致していないことになるのです。

指定されたヘッダファイルを見つけられない場合に、検討すべき可能性のある原因が、いくつか存在します。ソースコードはコンパイルできる状態にあるのか？その格納場所に間違いはないか？別の場所からソースコードをコピーしたのか？急いでヘッダを生成し、コンパイル後に削除していないか？コードをコンパイルするマシンに、システム・ヘッダファイルとコンパイラ・ヘッダファイルがすべて存在しているか？さらにもう1つ考慮すべき確認事項として、ヘッダファイルをインクルードするよう実際にコードを記述しているのか、という点があげられます。

ヘッダファイルを本当にインクルードする必要があるのか？

不明なヘッダファイルは場合により、インクルードする必要がないことがあります。例えば #include ディレクティブがソースコードの条件文の一部であるケースなどが、これに該当します。

不明なヘッダファイルを恐らくインクルードする必要がない可能性がある場合には、ソースコードで #include 文が記述されている箇所を調べることで、それを確認することが可能です。

#ifndef BUILDHYBRID
#include "drive/understeer.h"
#endif

上記の例では、understeer.h を検出できない理由として、プロジェクトのセットアップにおいて、プリプロセッサ・オプションの中で -DBUILDHYBRID をインクルードできなかったことが考えられます。このような場合には、どのようにコードがコンパイルされたのかを確認し、プロジェクト設定のインクルード・ディレクトリ・オプション（-I）と、プリプロセッサ・オプション（-D）の、どちらに問題があるのかを判断する必要があります。

ヘッダファイルを認識するために指定する必要のあるインクルード・ディレクトリはどれか？

通常、求められるインクルード・ディレクトリとは、ヘッダファイルが格納されているディレクトリです。

ただし、前述したように、エラーメッセージには以下のような、ファイル名の一部として関連するパスを含む #include ディレクティブが示されることがあります。

#include "drive/understeer.h"

このようなケースに必要とされるインクルード・ディレクトリは、相対パス名の上位階層のディレクトリです。つまり、この例の場合、ヘッダファイルの実際の保存先が c:/dev/project/include/drive/understeer.h とすると、c:/dev/project/include ディレクトリを、プロジェクトのインクルード・ディレクトリの1つとして指定する必要があります。

なぜ .inc ファイルの結果として、システム・ヘッダファイルが検出されないのか？

不明なヘッダファイルが、コンパイラのものか、オペレーティング・システム環境のものか判明したら、次にプロジェクトで使用している .inc コンパイラ設定ファイルを調整しなければなりません。特に、.inc ファイルに指定されているインクルード・ディレクトリを確認する必要があります。

arm_cross.inc ファイルの参考例を、次に示します。

/* ##################### ユーザ環境セクション ##################### */
/* 通常は、各環境に合わせた変更を、このセクションに加えます。    */

/* システム・ヘッダファイルの格納先を指定 */
#pragma cmdflag -S/usr/arm/include

.inc ファイルのコンテンツは、C コードとして処理されます。インクルード・ディレクトリは、#pragma cmdflag -S... の行で指定します。同時に #pragma cmdflag は、その行の後に続く記述を Imagix 4D ソースアナライザがオプションとして処理するよう指定しています。また -S オプションは、システム・インクルード・ディレクトリの指定を意味します。この指定により、標準の -I オプションで指定された通常の（アプリケーション）インクルード・ディレクトリと識別されるのです。

上記の例では、/usr/arm/include ディレクトリ1つのみが指定されています。Windows を使用している場合には、この記述を Windows 用の適切な表記に変更する必要があり、環境によって異なりますが、下記のようになります。

/* システム・ヘッダファイルの格納先を指定 */
#pragma cmdflag -Sc:/tools/arm/include

インクルード・ディレクトリを追加する場合は、.inc ファイルに新しい行を挿入します。

/* システム・ヘッダファイルの格納先を指定 */
#pragma cmdflag -Sc:/tools/arm/include
#pragma cmdflag -Sc:/tools/thirdparty/include

複数のインクルード・ディレクトリが記述されていると、ファイルに記述されている順序に従い検索が実行されます。

なぜプロジェクト設定の結果として、アプリケーション・ヘッダファイルが検出されないのか？

不明なヘッダファイルが、アプリケーション・コードの一部であると判断した場合にヘッダファイルを認識させるには、プロジェクト設定を修正する必要があります。その修正内容は、使用するコードの解析方法により、それぞれ異なります。

ダイアログ・ベースの解析方法 - この解析方法におけるインクルード・ディレクトリの指定は、[プロジェクト] > [データソース] ダイアログの [インクルードディレクトリ] タブで行います。この作業は、大きく2つの項目に分かれます。まずタブの上半部で、ルート・インクルード・ディレクトリを指定します。ヘッダファイルの検索にサブディレクトリを含めるのチェックボックスにチェックを付けると、ルートディレクトリ配下のディレクトリはすべて、インクルード・ディレクトリとして処理されます。Imagix 4D は内部的に、これらの各ディレクトリに対して -I オプションを生成します。またタブの下半分では、エントリフィールドに明示的に -I や -S オプションを指定することにより、タブの上半分で指定した以外の特定のインクルード・ディレクトリを追加します。

多くの場合、インクルード・ディレクトリの指定において、これら2つの設定はバランス良く活用しなければなりません。タブの上半分でルートディレクトリとして指定するディレクトリ階層が深すぎると、タブの下半分で個別に指定するインクルード・ディレクトリの数が非常に多くなります。逆に、タブの上半分でルートディレクトリとして指定するディレクトリ階層が浅すぎると、無意味あるいは不適切なディレクトリを、インクルード・ディレクトリとして指定することになります。無意味なディレクトリの数が多すぎると、ソースアナライザの処理速度の低下に繋がります。また不適切なディレクトリが指定された場合は、不完全なファイル名の一致が原因となり、誤ったヘッダファイルがインクルードされる可能性があるのです。

不明なインクルード・ディレクトリの特定を念頭に、各環境のディレクトリ構造を考慮の上 [インクルードディレクトリ] 設定を確認し、適切な変更作業を実施してください。この設定は通常、ディレクトリ階層の浅い場所にルートディレクトリを指定するか、タブの下半分にあるエントリフィールドで -Idir オプションを追加することになります。

Makeログから展開する解析方法 - この解析方法におけるインクルード・ディレクトリの設定は、ユーザが設定した [Makeログ] 処理のルールに従い、ログファイルの -I オプションから生成されます。求められるインクルード・ディレクトリが検出されない場合、まず [プロジェクト] > [データソース] ダイアログで [makeログから抽出] データソースを選択してください。これは、ダイアログの左にリスト表示される最初のデータソースが該当します。その後、ダイアログの [処理ルール] タブに加えた設定を確認してください。

設定に間違いがない場合は、求められるインクルード・ディレクトリのオプションを手動で追加します。まず [Makeログ] タブを表示し、[オプション] エントリフィールドに必要な -Idir を入力します。その次に、[Makeログを処理] ボタンをクリックしてください。入力した -Idir オプションは、作成される個々の [ダイアログベース(C/C++)] データソースすべてに伝播されます。

Microsoft Visual Studio ベースの解析方法 - この解析方法では、Visual Studio の .sln および .vcproj プロジェクト・ファイルから自動的にインクルード・ディレクトリ設定が生成されます。

最初に [プロジェクト] > [データソース] ダイアログの [プロジェクト] タブあるいは [ソリューション] タブに、Visual Studio の設定と [構成] が正確に設定されていることを確認してください。それでも不明なヘッダファイルを見つけられない場合は、Visual Studio のプロジェクト・ファイルから展開された設定に対して、明示的に必要なインクルード・ディレクトリに追加するため、タブの [オプション] エントリフィールドに -Idir オプションを追加します。