2016-12-09 11 views
0

いくつかのモジュールはそれぞれ独自のtest _ $(MODULE).cで独立してテストされます。 カバレッジのないモジュールを含む共有ライブラリが$(LIBRARY)で生成されました。 $(basename $ <).oは$(LIBRARY)のものを上書きする必要があります。何らかの理由で、オーバーライドされていないかのように結果が得られます。誰かがこれを見直して修正案を提案できますか?現在、私は5つのオブジェクトのそれぞれに対して非ジェネリックなgcovルールを持っています。これらのgcovは正しく動作します。以下に、ジェネリックルールとそのルールの使用方法を示します。この複雑な一般的なMakefileルールの構成方法

SHARED_OPTS=-O0 -Wall -Wextra -fPIC 
GOPTS=$(SHARED_OPTS) -g -coverage -pg 

%.gcov : % 
    @echo "\[email protected] generic (needs work)" 
    @-gcc $(GOPTS) -c -o test_$(basename $<).o test_$< 
    @-gcc $(GOPTS) -c -o  $(basename $<).o  $< 
    @-gcc $(GOPTS) -o gcov_test_$(basename $<) \ 
     test_$(basename $<).o \ 
     $(basename $<).o \ 
     -L . -l $(LIBRARY) 
    @-./gcov_test_$(basename $<) 
    @-gcov $< >[email protected] 2>&1 
    @echo "no Mac gprof: -gprof gcov_test_$(basename $<) gmon.out > $<.prof" 
    @$(call timestamp,[email protected]) 

Unicode.c.gcov: Unicode.c 

誰もが共有ライブラリを開発することによって、サポートを解析し、高効率、高品質のUnicodeの字句/上の連携に関心がある場合、私は査読や貢献者を持っているのが大好きです。

上に示したMakefileの断片は、githubのリポジトリである。具体的に、Cサブディレクトリダウン

https://github.com/jlettvin/Unicode

答えて

0

メイクファイルに問題が見つかったら、@は使用しないでください。コマンドラインが表示されなくなり、問題が表示されなくなります。また、-を避けるべきです:これらのコマンドのいずれかが失敗した場合、あなたは確かにレシピの残りの部分を実行したくないと思います。

それは、カット/ペーストの問題かどうかはわからないが、私はこれらの行は、少なくとも、間違っていることを前提とする必要があります。

@-gcc $(GOPTS) -c -o test_$(basename $<).o test_$< 
@-gcc $(GOPTS) -c -o  $(basename $<).o  $< 

私の知る限り、あなたのメイクファイルから最後に言うことができるようにこれらの行の単語はそれぞれtest_$<.c$<.cである必要があります。

+0

フィードバックいただきありがとうございます。これら2行の$ <の値は ".c"で終わります。これらの行は特定のルールで動作することに注意してください。一般的なルールではありません。私は非常にいくつかのオブジェクトの構築によって報告されたエラーは非常に少なく、モジュールの相互依存性はこの時点で非常にまれです。 ' - 'を使用すると、すべてのコンパイル時にすべてのオブジェクトに対してすべてのエラー(通常はnone)それにもかかわらず、私は今あなたの助言に従います。私が解決しようとしている実際の問題は他のところにあります。命名により、gcovのためにインストルメントされた.oファイルは最適化された.oライブラリファイルと共存することができます。 – jlettvin

関連する問題