************ ARRRRGGGGGHHHHH ************
マットの回答に投票してください。
コードを実行すると、環境変数が考慮されます。
この一文は、出力を再配置する方法に関して私が読んだすべてのドキュメントから明らかに欠落しています!
実際、その答えを少し拡張させてください。
GCOV_PREFIX はランタイム(ビルド時間に類似) の環境変数であり、gcov 出力ファイル (*.gcda) が書き込まれるルート ディレクトリを決定します。
GCOV_PREFIX_STRIP=X もランタイム変数であり、オブジェクト ファイル (文字列 XXXX.o) で見つかったパスから X 要素を削除する効果があります。
これが意味することは次のとおりです。
プロジェクトをビルドすると、オブジェクト ファイルは、その中に埋め込まれた各オブジェクト ファイルを担当する各ソース ファイルの場所へのフル パスと共に書き込まれます。
したがって、次のようなディレクトリ構造で実行可能な MyApp とライブラリ MyLib を作成しているとします。
/MyProject
|-MyApp
|--MyLib
MyLib は MyApp のサブディレクトリであることに注意してください
MyApp には 2 つのソース ファイルがあり、MyLib には 3 つのソース ファイルがあるとします。
「-coverage」フラグを使用してビルドすると、オブジェクト ファイルごとに 1 つずつ、合計 5 つの .gcno ファイルが生成されます。
MyApp の .o ファイルに埋め込まれた絶対パスは **/MyProject/MyApp/**a_source_file.cpp 同様に、MyLib の .o ファイルに埋め込まれたパスは **/MyProject/MyApp/MyLib/** になります。 another_source_file.cpp
さて、あなたが私のようで、それらのファイルを、それらが構築された場所とは異なるディレクトリ構造を持つ完全に別のマシンに移動するとしましょう。私の場合、ターゲット マシンは実際にはまったく異なるアーキテクチャです。そのマシンの /MyProject ではなく /some/deploy/path にデプロイします。
単純にアプリを実行すると、gcov データは、対応する .gcda ファイルをプロジェクト内の各オブジェクト ファイルの /MyProject/MyApp および /MyProject/MyApp/MyLib に書き込もうとします。これは、.o ファイルによって示されるパスであるためです。 all、MyApp、および MyLib は、一緒にアーカイブされた .o ファイルの単なるコレクションであり、関数ポインターなどを修正するための他の魔法が含まれています。
おそらく、それらのディレクトリは存在せず、おそらく root として実行していない (そうですか?) ため、それらのディレクトリも作成されません。Soooo..デプロイ場所/my/deploy/path内にgcdaファイルは表示されません。
それは完全に紛らわしいですよね!?!??!?!?!?
ここで GCOV_PREFIX と GCOV_PREFIX_STRIP の出番です。
(BAM ! こぶしが額に当たる) .o ファイルに埋め込まれたパスが実際には必要なものではないことを **** ランタイム **** に指示する必要があります。パスの一部を「削除」して、デプロイ ディレクトリに置き換えます。
したがって、GCOV_PREFIX=/some/deploy/path を介してデプロイ ディレクトリを設定し、生成された .gcda パスから /MyProject を取り除きたいので、GCOV_PREFIX_STRIP=1 を設定します。
これら 2 つの環境変数を設定して、アプリを実行し、/some/deploy/path/MyApp と /some/deploy/path/MyApp/MyLib を調べると、見よ、5 つの gcda ファイルが奇跡的に表示され、オブジェクトごとに 1 つです。ファイル。
注: ソース ビルドを使用しない場合、問題はさらに複雑になります。.o はソースを指しますが、gcda はビルド ディレクトリに相対的に書き込まれます。