cmakeファイルのGLOBが悪なのはなぜですか？
CMakeのドキュメントでは、コマンドについて file GLOB ：
GLOBを使用してソースツリーからソースファイルのリストを収集することはお勧めしません。ソースが追加または削除されたときにCMakeLists.txtファイルが変更されていない場合、生成されたビルドシステムは、CMakeに再生成を要求するタイミングを知ることができません。
ソースファイルのグロブ化は悪であるという、Webの2番目のディスカッションスレッド。
ただし、ソースが追加または削除されたことをビルドシステムに知らせるには、言うだけで十分です。
touch CMakeLists.txt
正しい？
そうすれば、CMakeLists.txtソースファイル名を挿入または削除します。覚えるのも難しいことではありません。ですから、file GLOB。
この引数の何が問題になっていますか？
問題は、あなたが一人でプロジェクトに取り組んでいないときです。
プロジェクトに開発者AとBがいるとします。
Aは新しいソースファイルx.cを追加します。彼はCMakeLists.txtを変更せず、x.cの実装が完了した後にコミットします。
Bはgit pullを実行し、CMakeLists.txtに変更が加えられていないため、CMakeは再度実行されず、コンパイル時にx.cが追加されていないためBはリンカーエラーを引き起こします。ソースファイルリスト。
それは本質的に悪ではありません-これには利点と欠点があります。これはStackOverflowの この回答 で比較的よくカバーされています。しかし、不注意に使用すると、依存関係の変更を無視し、コードベースの大部分のクリーンな再構築が必要になる場合があります。
個人的には、すべてのファイルを手動でビルドファイルに入力する必要がないように、小規模なプロジェクトまたは大規模なプロジェクトの特定のサブディレクトリで使用することに賛成です。 編集：私の好みが変わったので、現在それを避ける傾向があります。
ここに他の人が投稿した理由に加えて、globの最悪の問題は、異なるプラットフォームで異なるファイルリストを生成できることです。私が見るように、それはバグです。 OSXでは、globは大文字と小文字を区別しますが、ubuntuボックスでは無視しません。
グロビングは、CLionなどのCMakeLists.txtの限られたサブセットを理解し、安全ではないのでグロビングをサポートしないし、決してサポートしないようなもののすべてのコード検査を中断します。
Globedリストをダンプして貼り付けるスクリプトを作成します。これは非常に簡単で、CLionは実際に参照ファイルを見つけて、有用であると推測できます。そのようなスクリプトをツリーに追加して、他の開発者がバカにならずに実行できるようにすることもできますOR gitフックを設定してそれを実現します。
いずれかのディレクトリにドロップされたランダムなファイルが自動的にリンクされることはありません。これがトロイの木馬の発生方法です。
また、既知の定義にジャンプするコンテキストのないCLionは、裸足でハイキングするようなものです///なぜわざわざ。