为什么cmake文件GLOB邪恶？

Question

CMake doc说明命令file GLOB：

  

我们不建议使用GLOB从源树中收集源文件列表。如果在添加或删除源时没有更改CMakeLists.txt文件，则生成的构建系统无法知道何时要求CMake重新生成。

Web中的几个讨论线程第二个是通配源文件是邪恶的。

但是，要使构建系统知道已添加或删除了某个源，就足以说明

touch CMakeLists.txt

右？

然后，这比编辑CMakeLists.txt以插入或删除源文件名更省力。也难以记住。所以我认为没有任何理由反对file GLOB。

这个论点出了什么问题？

Answer 1

问题在于你并不是唯一一个在项目上工作的人。

假设项目有开发人员A和B.

A添加新的源文件x.c。他没有更改CMakeLists.txt并在完成实施x.c后提交。

现在B执行git pull，并且由于没有对CMakeLists.txt进行修改，因此CMake不会再次运行而B会在编译时导致链接器错误，因为x.c没有已被添加到其源文件列表中。

Answer 2

它不是本身邪恶 - 它有优点和缺点，在StackOverflow上的this answer相对较好。但是如果你不经意地使用它，你最终可能会忽略依赖项更改，并且需要对代码库的大部分内容进行干净的重建。

我个人赞成使用它 - 在较小的项目中，或在较大的子目录中 - 以避免必须手动将每个文件输入构建文件。 修改：我的偏好已经改变，我目前倾向于避免它。

Answer 3

除了其他人在这里发表文章的原因之外，恕我直言，glob最糟糕的问题是它可以在不同平台上产生不同的文件列表。如我所见，这是一个错误。在OSX中，glob忽略大小写敏感性，而在ubuntu框中则不区分大小写。

Answer 4

globbing破坏了CLion之类的所有代码检查功能，否则它们会理解CMakeLists.txt的有限子集，并且不了解并且永远不会支持globbing，因为它是不安全的。

编写脚本以转储全局列表并将其粘贴，这非常简单，然后CLion实际上可以找到引用的文件并将其推断为有用。甚至甚至可以将这样的脚本放到树上，以便其他开发人员可以不必笨拙地运行它，也可以设置git hooks来实现。

在任何情况下，放到某个目录中的随机文件都不会自动链接到木马程序。

没有上下文的CLion也跳到已知定义，什么也没有，就像赤脚远足///为什么要打扰。