【问题标题】:CMake: migration guide/ cheat sheet for make usersCMake:make 用户的迁移指南/备忘单
【发布时间】:2014-01-02 13:45:15
【问题描述】:

我正在考虑用 CMake 替换配置/制作风格的构建过程。 CMake 在复杂的事情上表现良好,但在简单的事情上更加冗长。 例如 GNU Make 文件:

你好: 回声“你好世界”>$@

在 CMake 中会是:

add_custom_command(输出你好 命令回显“你好世界”>你好) add_custom_target(所有都取决于你好)

另请参阅Adding a custom command with the file name as a target

实际上更像:

你好: 回声“你好世界”>你好 大家:你好

对于更复杂的构建,automatic variables 的缺失非常明显。

经过多次路由(似乎很难搜索 $@)我发现:

Automatic variables in CMake

这建议使用包装函数和

Path to target output file

建议使用接近自动变量的生成器表达式, 但不够接近。

我有几个相关的问题:

1a) 自提出该问题以来,CMake 本身或执行此操作的最佳实践是否有所进展?

1b) CMake 是否可能会提供与自动变量等效的功能? 如果没有,为什么不呢?

StackOverflow 和 Internet 上的其他地方都很好地涵盖了各个问题,但是:

2a) 是否有任何好的指南或备忘单可以帮助从直接使用 GNU make 进行迁移。

2b) 它们是 CMake 的最佳最佳实践指南吗?

这超出了 Makefile equivalent in CMake 中的建议。我正在逐步发展自己的风格,但我想避免无马车类型的错误和不必要的复杂性。

【问题讨论】:

  • 对于 2a+b,我真的在寻找一些经过编译的后见之明,例如您可能从有效 C++ 之类的书中得到的。你得到的不仅仅是一组规则,而是这些规则背后的推理。
  • 我找到了以下cmake反模式列表:voices.canonical.com/jussi.pakkanen/2013/03/26/…

标签: cmake


【解决方案1】:

这很难回答,因为 CMake 不等同于 make。例如,将 CMake 与 autotools 进行比较要容易得多,因为它是一个构建系统generator,而不是一个构建系统本身。

无论如何,让我们尝试提供一些答案。

1a+b) 不,因为提供此类构造不在 CMake 的范围和理念之内。
CMake 的语法通常比较冗长,带有明确的变量名称,例如 ${CMAKE_CURRENT_SOURCE_DIR} 以及命名的命令参数。它看起来更像是一种“经典”命令式编程语言,而不是像 Makefile 那样对依赖图进行专门的文本描述。
此外,CMake 的输出可以是 Makefile 或几乎任何其他内容,因此需要一定程度的抽象。

在您的情况下,最佳做法是使用宏:

macro(build_echo_foo ${target})
    add_custom_command(OUTPUT ${target}
        COMMAND echo "hello world" > ${target})
    add_custom_target(${target}_target ALL DEPENDS ${target})
endmacro()

build_echo_foo(hello)
build_echo_foo(another_hello)

Makefiles 鼓励作者尽可能通用,以尽量减少打字,CMake 试图使事情尽可能明确,例如鼓励维护者明确列出源文件而不是提供通配符。

2a+b) 回答这个问题并不完全属于 Stack Overflow 的范围,但我会这么说。 最好的灵感来源是使用这个系统的开源项目。截至 2014 年,有大量备受瞩目的项目已迁移到 CMake。您甚至可以学习 CMake 自己的源代码,它使用自己作为构建系统。

【讨论】:

  • 我绝对不想强制编写构建文件。然而,cmake 仍然试图是声明性的(主要是)。 add_executable() 等只是您尝试做的更高级别的声明。所以我不同意 cmake 在风格上是必不可少的。
  • @BruceAdams 是的,毕竟它们被命名为 CMake 列表是有原因的。严格来说,cmake 的命令性方面在于它能够指定自定义命令,因为我们告诉它如何 构建目标,而不是依赖其默认机制。
  • 我的牛肉不是冗长而是重复。如果我已经为 OUTPUT 指定了值,我不想重复它们。包装在宏或函数中并不理想,因为不同的命令可能会引用不同的输出文件集和依赖项。我最终可能会得到许多这样的函数,可能名字不正确。所以我认为这既是 cmake 语法的问题,也可能是通过采用一些好的规则可以避免的问题。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2022-07-08
  • 2020-11-10
  • 1970-01-01
  • 1970-01-01
  • 2011-10-30
  • 1970-01-01
  • 2010-09-15
相关资源
最近更新 更多