cmake 是否使用约定优于配置?

发布于 2024-12-11 00:43:59 字数 379 浏览 0 评论 0原文

据说 Maven 采用了约定优于配置

我不想进行任何错误的比较,但据我了解 cmake 可以为 C++ 项目填补类似的空白就像 Maven 可以用于 Java 项目一样。

那么,cmake 是否有一些配置约定,或者每个项目的配置都是唯一的? (Wrt.文件布局、测试布局、构建输出等)

Maven is said to employ a form of Convention over Configuration.

I don't want to draw any wrong comparisons but as far as I understand cmake can fill a similar roll for a C++ project as maven can for a Java project.

So, does cmake have some Conventions over Configuration, or is each project configured uniquely? (Wrt. file layout, test layout, build output, etc.)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

把梦留给海 2024-12-18 00:43:59

在体验了 Maven 3 的优雅之后,我也寻找一种约定优于配置的 C maven 风格的系统。 ...

我还检查了 CMAKE,在创建骨架后,有一些事情很突出。

  1. CMAKE 有时是声明性的,有时是程序性的,而你总是会得到一个丑陋的混合结果。又名,它是不带括号的 C 的 ANT。

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

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

After experiencing the elegance of Maven 3, I also looked for a convention over configuration C maven style system. ...

I also checked out CMAKE, after creating a skeleton a few things stood out.

  1. CMAKE is sometimes declarative, sometimes procedural, and your always going to end up with an ugly mix. AKA, it's ANT for C without brackets.

  2. CMAKE itself IS portable, alas your project will need platform specifics handled and you better know them in advance. CMAKE modules exist to supposedly help with this, unfortunately their re-usability appears more like the promise of Ansible roles... Theoretically possible, but in practice they end up as decent way for you to organize all that complexity required.

In other words, CMAKE is in no shape or form like Maven. It's more like a lower level ANT, that allows you to use the "Cross-platform" DSL to generate platform specific makefiles.

甜嗑 2024-12-18 00:43:59

我们强烈鼓励的一个约定是进行“源外”构建,其中构建目录包含所有构建产品,并且与源代码树完全分开,通常源和构建是兄弟姐妹:

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

我们始终推荐此策略的两个主要原因(1) 保持源代码树中没有构建产品,因此很容易知道自版本控制系统上次更新以来发生了什么变化;(2) 以便您可以为任何给定的源代码树拥有多个构建树,并且不用担心构建产品和/或设置干扰另一方。

我最近注意到我正在做的一个项目无意中在源代码树中生成了一些 python 文件。不过,当我尝试在不同的构建树中同时构建 x86 和 x64 构建时,我才注意到这一点......突然生成的 python 文件有一些行重复和混合。将其更改为生成到构建树中,一切都很好。

不过,这只是 CMake 良好实践的一部分,除了运行这些项目的聪明人的常识和纪律之外,没有其他任何东西强力强制执行......

The one convention that we strongly encourage is to do "out of source" builds, where the build directory contains ALL build products, and is completely separate from the source tree, usually source and build are siblings:

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

Two primary reasons we always recommend this strategy are (1) to keep the source tree clean of build products, so it is easy to tell what has changed since your last update from your version control system and (2) so that you may have multiple build trees for any given source tree and not worry about the build products and/or settings from one interfering with the other one.

I recently noticed a project I was working on had inadvertently generated some python files in the source tree. I only noticed it, though, when I tried to build both the x86 and x64 builds simultaneously in different build trees... and suddenly the generated python files had some lines duplicated and intermixed. Changed it to generate into the build tree, and all was well.

This is all just part of CMake good practice, though, and is not strongly enforced by anything other than the common sense and discipline of the smart people running these projects...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文