我期待在通过CMake更换配置/化妆风格的构建过程。 CMake的对复杂的东西表现良好，但它是简单的事情，更详细。 例如在GNU制作文件：
hello:
echo "hello world" >$@
在CMake的将是：
add_custom_command(OUTPUT hello
COMMAND echo "hello world" > hello)
add_custom_target(all ALL DEPENDS hello)
另请参见添加自定义命令和文件名作为目标 。
这实际上是更喜欢：
hello:
echo "hello world" >hello
all: hello
随着越来越多的复杂的构建没有自动变量是非常明显的。
各地多路由后（这似乎是难以寻找$ @），我发现：
在CMake的自动变量
这表明使用封装功能与
目标路径输出文件
这表明使用生成器表达式是接近自动变量，但不够紧密。
我有几个相关问题：
1A）已CMake的本身还是这样做的最佳做法感动了自认为有人问？
图1b）是很可能的CMake都不会提供一个相当于自动变量？ 如果不是，为什么不呢？
个别问题都相当不错覆盖堆栈溢出和其他地方在互联网上，但是：
2A）是否有良好的导向或作弊表，以帮助使用GNU直接进行迁移。
图2b）他们是任何好的最佳实践指南为CMake的？
这是超出了建议的Makefile相当于CMake的 。 我逐渐演变我自己的风格，但我想，以避免不用马拉的车类型的错误和不必要的复杂性。
这是很难回答，因为CMake的不等同于做。 这是很容易向CMake比较自动工具，例如，因为它是一个构建系统， 发电机 ，而不是通过自身构建系统。
无论如何，让我们尝试提供一些答案。
1A + b）否，因为它不是在CMake的的范围和理念，以提供这样的构建体。
CMake的语法通常比较冗长上的侧面是，与明确的变量名，如${CMAKE_CURRENT_SOURCE_DIR}以及命名的命令参数。 它看起来更像是一个“经典”的命令式编程语言，而不是依赖关系图，其Makefile文件的特殊文本描述。
此外，CMake的输出可生成文件或几乎任何东西，因此需要抽象的一定水平。
在你的情况下，最好的做法是使用宏：
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)
凡Makefile文件鼓励笔者尽可能通用，以减少打字，CMake的试图通过鼓励维护者明确列出源文件，而不是提供通配符来使事情毫不含糊地，例如。
要回答这个图2a + b）是不完全的堆栈溢出的范围，但我会说这个。 灵感的最佳来源是使用该系统的开源项目。 截至2014年，有相当数量的已迁移到CMake的高调项目。 你甚至可以学习的CMake自己的源代码，以自身作为构建系统。
