CMake：面向用户的迁移指南/备忘单 [英] CMake: migration guide/ cheat sheet for make users
问题描述
我正在考虑用CMake代替配置/制作样式的构建过程。 CMake在复杂的东西上表现不错，但在简单的东西上却更为冗长。
例如GNU Make文件：
I'm looking at replacing a configure/make style build process with CMake. CMake performs well on the complicated stuff, but it is more verbose on simple things. For instance the GNU Make file:
hello:
echo "hello world" >$@
在CMake中是：
add_custom_command(OUTPUT hello
COMMAND echo "hello world" > hello)
add_custom_target(all ALL DEPENDS hello)
另请参见 添加带有文件名的自定义命令作为目标 。
See also Adding a custom command with the file name as a target.
实际上更像是：
hello:
echo "hello world" >hello
all: hello
使用更复杂的版本，缺少自动变量
With more complex builds the absence of automatic variables is very noticeable.
经过大量路由（似乎很难搜索$ @）后，我发现：
After much routing around (it seems to be hard to search for $@) I found:
使用包装函数和
，这建议使用与自动变量（
接近但不接近）的生成器表达式
which suggests using generator expressions that are close to automatic variables, but not close enough.
我有几个相关问题：
1a）具有CMake本身或最佳实践
1a) Has CMake itself or best practice for doing this moved on since that question was asked?
1b）CMake是否有可能提供与自动变量等效的功能？
如果不是，为什么不呢？
1b) Is it likely CMake will ever provide an equivalent to automatic variables? If not, why not?
堆栈溢出和Internet上的其他地方都很好地解决了个人问题，但是：
Individual problems are quite well covered on Stack Overflow and elsewhere on the Internet, but:
2a）是否有任何好的指南或备忘单，以帮助直接使用GNU make进行迁移。
2a) Are there any good guides or cheat sheets to help with migrating from using GNU make directly.
2b）它们是否最好？
2b) Are they any good best practice guides for CMake?
这超出了 与CMake等效的Makefile 。我正在逐步发展自己的风格，但是我想避免无马车类型错误和不必要的复杂性。
That is beyond the suggestions in Makefile equivalent in CMake. I am gradually evolving my own style, but I would like to avoid horseless carriage type mistakes and needless complexity.
推荐答案
回答，因为CMake不等于make。例如，将CMake与自动工具进行比较要容易得多，因为它是构建系统 generator 而不是构建系统本身。
This is hard to answer, because CMake is not equivalent to make. It's much easier to compare CMake to autotools, for example, because it is a build system generator rather than a build system by itself.
无论如何，让我们尝试提供一些答案。
Regardless, let's try to provide some answers.
1a + b）不，因为提供这样的构造不在CMake的范围和理念之内。
CMake的语法通常更多地是冗长的，具有显式变量名称，例如 $ {CMAKE_CURRENT_SOURCE_DIR} 以及命名的命令参数。它看起来更像是一种经典的命令式编程语言，而不是对Makefile所依赖的关系图的专门文本描述。
另外，CMake的输出可以是Makefile或几乎任何其他东西，因此一定程度的
1a+b) No, because it is not in the scope and philosophy of CMake to provide such constructs.
CMake's syntax is usually more on the side of verbosity, with explicit variable names such as ${CMAKE_CURRENT_SOURCE_DIR} as well as named command parameters. It looks more like a "classical" imperative programming language rather than a specialized textual description of a dependency graph which Makefiles are.
Also, CMake's output can be Makefiles or pretty much anything else, so a certain level of abstraction is needed.
在您的情况下，最佳实践是使用宏：
The best practice in your case would be to use macros:
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尝试使内容尽可能明确，例如鼓励维护者明确列出源文件而不是提供通配符。
Where Makefiles encourage the author to be as generic as possible, to minimize typing, CMake tries to make things as unambiguous as possible, for example by encouraging the maintainer to explicitly list source files instead of providing wildcards.
2a + b）回答并非完全正确他的范围是Stack Overflow，但我会这样说。
最好的灵感来源是使用此系统的开源项目。截至2014年，已经有很多高知名度的项目迁移到CMake。您甚至可以研究CMake自己的源代码，该源代码将自身用作构建系统。
2a+b) Answering this is not exactly in the scope of Stack Overflow, but I'll say this. The best source of inspiration is open-source projects using this system. As of 2014, there are a good number of high-profile projects that have migrated to CMake. You can even study CMake's own source code, which uses itself as build system.
这篇关于CMake：面向用户的迁移指南/备忘单的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
