cmake 是不是使用约定而不是配置？

Posted 2023-02-23

【中文标题】cmake 是不是使用约定而不是配置？

【英文标题】：Does cmake use convention over configuration?cmake 是否使用约定而不是配置？

【发布时间】：2011-10-19 18:31:15

【问题描述】：

Maven is said to 采用Convention over Configuration 的形式。

我不想做任何错误的比较，但据我了解，cmake 可以为 C++ 项目填补类似的角色，就像 maven 对 Java 项目所做的那样。

那么， cmake 有一些优于配置的约定，还是每个项目的配置都是唯一的？ （写文件布局、测试布局、构建输出等）

【问题讨论】：

我实际上是从了解 Maven 的人的角度回答了你的问题。

【参考方案1】：

在体验了 Maven 3 的优雅之后，我还寻找了一个约定优于配置 C 的 maven 样式系统。 ...

我还检查了 CMAKE，在创建了一个骨架之后，一些东西很突出。

CMAKE 有时是声明性的，有时是程序性的，而且你总是会得到一个丑陋的组合。又名，它是不带括号的 C 的 ANT。

CMAKE 本身是可移植的，可惜您的项目需要处理平台细节，您最好提前了解它们。 CMAKE 模块的存在据说可以帮助解决这个问题，不幸的是，它们的可重用性看起来更像是 Ansible 角色的承诺......理论上是可能的，但在实践中，它们最终成为您组织所有所需复杂性的体面方式。

换句话说，CMAKE 与 Maven 不同。它更像是一个较低级别的 ANT，它允许您使用“跨平台”DSL 来生成特定于平台的 makefile。

【参考方案2】：

我们强烈鼓励的一种约定是进行“非源代码”构建，其中构建目录包含所有构建产品，并且与源代码树完全分开，通常源代码和构建是同级的：

projects
  proj1-build-x86
  proj1-build-x64
  proj1-src

我们始终推荐此策略的两个主要原因是 (1) 保持源代码树中没有构建产品，因此很容易从版本控制系统中判断自上次更新以来发生了什么变化；(2) 以便您对于任何给定的源代码树，可能有多个构建树，而不必担心其中一个的构建产品和/或设置会干扰另一个。

我最近注意到我正在处理的一个项目无意中在源代码树中生成了一些 python 文件。但是，当我尝试在不同的构建树中同时构建 x86 和 x64 构建时，我才注意到它......突然生成的 python 文件有一些重复和混合的行。将其更改为生成到构建树中，一切正常。

不过，这只是 CMake 良好实践的一部分，除了运行这些项目的聪明人的常识和纪律之外，并没有得到任何强制执行...

【讨论】：

这当然是一个约定，但它与“约定优于配置”有什么关系？ Cmake 是否会自动检测这种类型的项目结构以自动配置自身以进行源外构建，还是必须显式配置？