web-dev-qa-db-ja.com

Cプロジェクトの実装ソースファイルの切り替え

簡単にするために、次のCプロジェクト構造があるとします。

src/
  utils/
    logger.c
    logger.h
   main.c
   secondary_component.c

main.cは次で始まります：

#include "utils/logger.h"

コードとその構造をそのままにしておきたいのですが、logger.c、logger.hをスタブ化し、secondary_component.cのコンパイルを避けます（つまり、mainのサブセットのみを使用します。 logger）。たとえば、ファイルへの通常のlogger.c書き込みの代わりに、スタブバージョンには単純なprintfが含まれます。

私が試みた解決策：追加のフォルダーstubbed_src/utilsを作成し、そのフォルダー内に新しいlogger.c、logger.hを配置します。次に、実行します。

clang -iquote stubbed_src -iquote src -o main_proj main.c stubbed_src/utils/logger.c

目標は、clangが#include logger.h内のmain.cを検出すると、最初にstubbed_srcフォルダーを調べてそれを見つけることです（したがって、元のsrc/utils/logger.hを無視します）。残念ながら、clangは常に現在のフォルダーを最初に調べます（つまり、srcで始まるutils/logger.hを探します。ここで、main.cが見つかります）、見つからない場合にのみ、iquoteフォルダを調べます。その場合、src/utilsに実装が見つかると常に停止します。

以前はclangコマンドラインがありました 回避策 この現在の作業ディレクトリの動作を無効にしましたが、その後非推奨になりました。

main.cの#includeを角括弧で囲まれた#includeに変更する場合は、-Iにそのような制限がないため、-Iを使用しても問題は解決します。現在のディレクトリ。しかし、これは 不適切な使用法 の山括弧であり、この場合はmain.cを変更することもできません。

理想的には、私のスタブバージョンのlogger.c、logger.hはサイズが大幅に縮小され、main.cで使用される関数のみが実装されます。たとえば、secondary_component.cのみをコンパイルしたいので、main.cによって呼び出されたlogger関数を破棄します。さらに、secondary_component.cによって呼び出されるこれらの無関係な関数は、独自の#include要件を元のloggerファイルに導入し、これらの余分な#includesをコンパイルしないようにしています。 main.cを単純にコンパイルして、スタブ化されたlogger関数で動作させ、余分なファイルのコンパイルを回避できるようにしたいと思います。

logger.c、logger.hの代替/スタブアウト実装を使用する方法に関する他の提案はありますか？

ccompilermodularizationclang
1
ChaimKut

Cで関数をモックする（または別の実装を使用する）ときの通常の方法は、ビルドプロセスで異なる.cソースファイルを使用することです。通常、ヘッダーファイルは置き換えられません。

ヘッダーファイルを本当に置き換える必要がある場合は、#include "header.h" includeディレクティブはnotである必要があります。現在のソースのディレクトリから直接検索できるファイルを参照してください。 C標準では、#include "..."フォームは、常に現在のディレクトリを最初に調べてから、他のパスを調べ始める必要があります。

4
Bart van Ingen Schenau