CMake clean/configureを使用する場合は? 編集
CMakeはファイルCMakeCache.txt
にいくつかの情報をキャッシュします。 これは、例えば、特定のパッケージが見つかったディレクトリと-D
を使用して渡された定義です。
--cmake-clean-cache
を使いたい場合のいくつかの例:
- 以前に見つかったパッケージは、別の場所から見つけたり使用したりしたいので、もう一度検索する必要があります
- 前に定義を渡しています。
cmakeは、含まれているCMakeファイルが変更されたときにconfigureステップを自動的に実行します。 しかし、ロジックが追加の/外部状態/ファイルに依存することがあり、configureステップを再度実行するにはCMakeが必要です。 (特定の非CMakeファイルを変更すると再構成がトリガーされることをCMakeに伝える方法があります。 したがって、configureステップを再度実行する必要があるが、CMakeが自動的に実行しない場合は、CMakeファイルをタッチしてインクルードするか、--cmake-force-configure
を渡すだけです。
make clean
を呼び出したい場合は、コードにコンパイラの警告があるかどうかを再確認します。 ソースファイルがコンパイルされると、一般的には、それ(または含まれているヘッダー)が変更されるまで再コンパイルされません。 その最初のビルドではコンパイラの警告が表示されるかもしれませんが、連続したビルドでは(ファイルが変更されていないと仮定して)コンパイラの警告は再び表示されません。 すべてのファイルが再コンパイルされていることを確認するには、--cmake-clean-first
を渡すのが良い方法です。
場合によっては、ビルドディレクトリに以前のビルドからの追加の状態が含まれていることがあります(例えば、以前のバージョンのパッケージがビルドディレクトリにいくつかのファイルを作成したなど)。 それらはクリーンアップされず、それらを作成するロジックが削除された後でも、次のビルドに影響を与える可能性があります。 したがって、これはbuild
ディレクトリ全体を削除するのに役立ちます。
私が削除することをお勧めする別のケースbuild
ディレクトリは、あなたが理解していない問題に遭遇したときです。 また、問題をチケットで報告する前に、新しいビルドを使用して問題を再現することもできます。 新しいビルドから始めると、過去に行われたことに基づいて、時間の経過とともに構築された厄介な状態が解決される可能性があります。
ccache
を設定している場合、ビルドアーティファクトの多くが以前にキャッシュされているため、通常は新しいビルドに完全な時間がかからないため、完全な再構築はそれほど高価ではありません。