Maven is said to使用Convention over Configuration的形式。
我不想绘制任何错误的比较，但据我所知，cmake可以填充类似于C ++项目的滚动，因为maven可以用于Java项目。
那么， cmake是否有一些基于配置的约定，或者每个项目是否都是唯一配置的？ （Wrt。文件布局，测试布局，构建输出等）
答案 0 :(得分：2)
我们强烈建议的一个约定是“out of source”构建，其中构建目录包含所有构建产品，并且与源树完全分离，通常源和构建是兄弟姐妹：
projects
proj1-build-x86
proj1-build-x64
proj1-src
我们总是推荐这个策略的两个主要原因是：（1）保持源代码树对构建产品的清洁，因此很容易判断自上次从版本控制系统更新后发生的变化，以及（2）以便您对于任何给定的源树，可能有多个构建树，而不必担心构建产品和/或设置会干扰另一个源代码树。
我最近注意到我正在处理的一个项目无意中在源代码树中生成了一些python文件。我只注意到它，当我尝试在不同的构建树中同时构建x86和x64构建时......突然生成的python文件有一些重复和混合的行。将其更改为生成到构建树中，一切都很顺利。
这只是CMake良好实践的一部分，并且除了运行这些项目的聪明人的常识和纪律之外，其他任何事情都没有强制执行......
答案 1 :(得分：2)
在体验了Maven 3的优雅之后，我还寻找了一个关于配置C maven风格系统的约定。 ......
我还检查了CMAKE，在创建了一个骨架后，有一些东西脱颖而出。
CMAKE有时是声明性的，有时是程序性的，你总是会以丑陋的混音结束。 AKA，它是没有括号的C的ANT。
CMAKE本身是便携式的，唉你的项目需要处理平台细节，你最好提前知道它们。 CMAKE模块应该可以帮助解决这个问题，不幸的是，它们的可重用性似乎更像是Ansible角色的承诺......理论上可行，但实际上它们最终会成为组织所需复杂性的好方法。
换句话说，CMAKE没有像Maven那样的形状或形式。它更像是一个较低级别的ANT，它允许你使用＆＃34;跨平台＆＃34; DSL用于生成特定于平台的makefile。