2009-05-11 17 views
2

Cソースファイルに含まれるすべての可能なファイルのリストを取得したいと考えています。どのファイルが含まれている可能性がありますか?

他の#ディレクティブと合併症があることを理解しています(たとえば、#ifdefがインクルードを妨げたり、インクルードを追加するなど)。私が探しているのは、含まれているかもしれないファイルのリストです。

既にこれを行うツールはありますか?

私がコンパイルしているファイルは.oのみになり、標準のCライブラリは含まれていません。私はそれがうねっていると思うが、私たちは理由がある。

私ができるようにしたいのは、.oに何か貢献した可能性のあるファイルのリストを持っていて、変更されているかどうかを確認できます。

+0

標準のCライブラリを指していると思いますか? – hbw

+0

どのツールセットを使用していますか? –

+0

cpp -x c -dI main.c | egrep '#[0-9] + "[^"] * "[0-9] *' | egrep -o '" [^ "] *"' | sort -u –

答えて

10

gccの場合:

-M Instead of outputting the result of preprocessing, output a rule 
    suitable for make describing the dependencies of the main source 
    file. The preprocessor outputs one make rule containing the object 
    file name for that source file, a colon, and the names of all the 
    included files, including those coming from -include or -imacros 
    command line options. 

これは基本的にあなたが望むことをします。 (すべては-Mで始まります)には、この出力のさまざまなバリエーションがあります。

+0

ありがとう! #ifdefがそれを削除しても、すべての#include行がカウントされるようにする方法はありますか? –

+0

#includeの中にあるすべてのものが必要な場合は、実際にインクルードされているかどうかに関係なく、おそらく "grep"と一緒に行くのが最善でしょう。 – sth

+0

grepを使ってすべての-P '\ #include "。*"を検索するのは簡単ですが、インクルードされたファイル自体は扱えません。これを処理するために、「1つのライナー」はかなり複雑になるようです。 –

1

プリプロセッサステップのみを実行できます。ほとんどのコンパイラでこれが可能です。

もちろん、結果のファイルを読み込むのに忙しい作業が必要です。

1

すべての可能なファイルはありますか?それをする方法はありません。

+0

私は彼が "条件付きディレクティブが取り除かれた場合に含まれるすべてのファイル"を意味すると思います。 "#include行を書くことにした場合、インクルードされていたかもしれないファイル" – Chuck

2
私の構文が錆びている

、しかし...

grep -ir "#include " *.c 

はうまくいくかもしれない...

2

gccを使用する場合は、プリプロセッサダンプ調べることができます:manページを引用

[~]> gcc -E /usr/include/cups/dir.h|grep "#" 
# 1 "/usr/include/cups/dir.h" 
# 1 "<built-in>" 
# 1 "<command line>" 
# 1 "/usr/include/cups/dir.h" 
# 26 "/usr/include/cups/dir.h" 
# 1 "/usr/include/sys/stat.h" 1 3 4 
# 73 "/usr/include/sys/stat.h" 3 4 
# 1 "/usr/include/sys/_types.h" 1 3 4 
# 32 "/usr/include/sys/_types.h" 3 4 
# 1 "/usr/include/sys/cdefs.h" 1 3 4 
# 33 "/usr/include/sys/_types.h" 2 3 4 
# 1 "/usr/include/machine/_types.h" 1 3 4 
# 34 "/usr/include/machine/_types.h" 3 4 
# 1 "/usr/include/i386/_types.h" 1 3 4 
# 37 "/usr/include/i386/_types.h" 3 4 
# 70 "/usr/include/i386/_types.h" 3 4 
# 35 "/usr/include/machine/_types.h" 2 3 4 
# 34 "/usr/include/sys/_types.h" 2 3 4 
# 58 "/usr/include/sys/_types.h" 3 4 
# 94 "/usr/include/sys/_types.h" 3 4 
# 74 "/usr/include/sys/stat.h" 2 3 4 
# 1 "/usr/include/sys/_structs.h" 1 3 4 
# 88 "/usr/include/sys/_structs.h" 3 4 
# 79 "/usr/include/sys/stat.h" 2 3 4 
# 152 "/usr/include/sys/stat.h" 3 4 
# 228 "/usr/include/sys/stat.h" 3 4 
# 248 "/usr/include/sys/stat.h" 3 4 
# 422 "/usr/include/sys/stat.h" 3 4 
# 27 "/usr/include/cups/dir.h" 2 
# 42 "/usr/include/cups/dir.h" 
+1

プリプロセッサのダンプに関する問題は、その特定のgccの呼び出しに含まれていたものを表示することです。コマンドラインで「魔法」を定義していれば、まったく異なるファイルセットが含まれているはずです。 –

1

単にあなたがその非標準何か検査によって伝えることができるだろうけれども、誰かが... ...

#define tricksy(foo,bar) <foo##bar> 
#define precious tricksy(ios, tream) 
#include precious 
int main(int, char **) 
{ 
     std::cout << "Hobbits!" << std::endl; 
     return 0; 
} 

を犯した可能性があるための#includeのソースは、十分であることが保証されていないgrepをああ、 が含まれています。これは、<>または ""が見つからないためです。

非公開の例は、コマンドライン定義に応じて異なるライブラリルートディレクトリをトークンペーストすることです。

+0

これは私の質問に対する一般的な解決策の問題ですが、私が取り組んでいるソースを使って、そんなことをするのに狂った人はいなかった。ソースをグロッピングする際の問題は、インクルードされているすべてのファイルを知りたいということです。 –

+1

+1軽度のもっともらしいエッジケースであっても可能性を識別する。しかし、私は今、このようなトリックを使う誘惑を持っています... – RBerteig

関連する問題