我绝对会投票给 premake。虽然它不像它的前辈那么强大，但它的主要优点是简单性和易用性。使编写多编译器、多平台代码变得轻而易举，并本机生成 Visual Studio 解决方案、XCode 项目、Makefile 等，无需任何额外的工作。
I'd definitively put my vote up for premake. Although it is not as powerful as it's older brothers, it's main advantage is absurd simplicity and ease of use. Makes writing multi-compiler, multi-platform code a breeze, and natively generates Visual Studio solutions, XCode projects, Makefiles, and others, without any additional work needed.
So, judging purely by the criteria set forth in the question, the build system that seems like the best fit is probably waf - pure Python, provides support for C++ and other languages, general, powerful, not a DSL.
However, from my personal experience, I prefer CMake for C++ projects. (I tried CMake, SCons, and waf, and liked them in roughly that order). CMake is a general solution, but it has built-in support for C++ that makes it nicer than a more generic solution when you're actually doing C++.
CMake's build model for C++ is more declarative and less imperative, and thus, to me, easier to use. The CMake language syntax isn't great, but a declarative build with odd syntax beats an imperative build in Python. Of the three, CMake also seems to have the best support for "advanced" things like precompiled headers. Setting up precompiled headers reduced my rebuild time by about 70%.
Other pluses for CMake include decent documentation and a sizable community. Many open source libraries have CMake build files either in-tree or provided by the CMake community. There are major projects that already use CMake (OGRE comes to mind), and other major projects, like Boost and LLVM, are in the process of moving to CMake.
Part of the issue I found when experimenting with build systems is that I was trying to build a NPAPI plugin on OS X, and it turns out that very few build systems are set up to give XCode the exact combination of flags required to do so. CMake, recognizing that XCode is a complex and moving target, provides a hook for manually setting commands in generated XCode projects (and Visual Studio, I think). This is Very Smart as far as I'm concerned.
Whether you're building a library or an application may also determine which build system is best. Boost still uses a jam-based system, in part because it provides the most comprehensive support for managing build types that are more complex than "Debug" and "Release." Most boost libraries have five or six different versions, especially on Windows, anticipating people needing compatible libraries that link against different versions of the CRT.
I didn't have any problems with CMake on Windows, but of course your mileage may vary. There's a decent GUI for setting up build dependencies, though it's clunky to use for rebuilds. Luckily there's also a command-line client. What I've settled on so far is to have a thin wrapper Makefile that invokes CMake from an objdir; CMake then generates Makefiles in the objdir, and the original Makefile uses them to do the build. This ensures that people don't accidentally invoke CMake from the source directory and clutter up their repository. Combined with MinGW, this "CMake sandwich" provides a remarkably consistent cross-platform build experience!
Of course that depends on what your priorities are. If you are looking primarily for ease of use, there are at least two new build systems that hook into the filesystem to automatically track dependencies in a language agnostic fashion.
The one that seems to be the best performing, portable, and mature (and the one I have actually used) is tup. The guy who wrote it even maintains a toy linux distro where everything is a git submodule, and everything (including the kernel) is build with tup. From what I've read about the kernel's build system, this is quite an accomplishment.
Also, Tup cleans up old targets and other cruft, and can automatically maintain your .gitignore files. The result is that it becomes trivial to experiment with the layout and names of your targets, and you can confidently jump between git revisions without rebuilding everything. It's written in C.
If you know haskell and are looking for something for very advanced use cases, check out shake:
The Selenium project is moving over to Rake, not because its the best but because it handles multiple languages slightly better than all the other build tools and is cross platform (developed in Ruby).
All build tools have their issues and people learn to live with them. Something that runs on the JVM tends to be really good for building apps so Ant, Maven (i know its hideous), Ivy, Rake
language agnostic: it doesn't support c/c++t yet, only java but it is extensible via plugins written in java so adding more compilers support is not a problem
extensible: yes, you can implement smooth function via java plugin, you can also create smooth function via defining it as expression built of other smooth functions.
I would prefer to avoid writing any XML: you won't see a single line of it in smooth build
发布评论
评论（8）
我绝对会投票给 premake。虽然它不像它的前辈那么强大，但它的主要优点是简单性和易用性。使编写多编译器、多平台代码变得轻而易举，并本机生成 Visual Studio 解决方案、XCode 项目、Makefile 等，无需任何额外的工作。
I'd definitively put my vote up for premake. Although it is not as powerful as it's older brothers, it's main advantage is absurd simplicity and ease of use. Makes writing multi-compiler, multi-platform code a breeze, and natively generates Visual Studio solutions, XCode projects, Makefiles, and others, without any additional work needed.
因此，纯粹根据问题中提出的标准来判断，最适合的构建系统可能是 waf - 纯Python，提供对C++和其他语言的支持，通用，功能强大，不是DSL。
然而，从我个人的经验来看，对于 C++ 项目，我更喜欢 CMake。 （我尝试了 CMake、SCons 和 waf，并且大致按照这个顺序喜欢它们）。 CMake 是一个通用解决方案，但它具有对 C++ 的内置支持，这使得当您实际使用 C++ 时它比更通用的解决方案更好。
CMake 的 C++ 构建模型更具声明性，更少命令性，因此对我来说更易于使用。 CMake 语言语法不是很好，但是具有奇怪语法的声明式构建胜过 Python 中的命令式构建。在这三者中，CMake 似乎对预编译头等“高级”内容的支持最好。设置预编译头使我的重建时间减少了大约 70%。
CMake 的其他优点包括良好的文档和规模较大的社区。许多开源库都在树内或由 CMake 社区提供 CMake 构建文件。有些主要项目已经使用了 CMake（我想到的是 OGRE），而其他主要项目（例如 Boost 和 LLVM）正在迁移到 CMake。
我在尝试构建系统时发现的部分问题是，我试图在 OS X 上构建 NPAPI 插件，结果发现很少有构建系统能够为 XCode 提供执行此操作所需的确切标志组合。 CMake 认识到 XCode 是一个复杂且不断变化的目标，因此提供了一个钩子，用于在生成的 XCode 项目（我认为还有 Visual Studio）中手动设置命令。就我而言，这是非常聪明的。
无论您是构建库还是应用程序，也可能决定哪种构建系统最好。 Boost 仍然使用基于 jam 的系统，部分原因是它为管理比“调试”和“发布”更复杂的构建类型提供了最全面的支持。大多数 boost 库都有五到六个不同的版本，尤其是在 Windows 上，预计人们需要链接到不同版本的 CRT 的兼容库。
我在 Windows 上使用 CMake 没有遇到任何问题，但当然您的情况可能会有所不同。有一个不错的 GUI 用于设置构建依赖项，但用于重建时很笨重。幸运的是还有一个命令行客户端。到目前为止，我已经决定使用一个瘦包装器 Makefile，从 objdir 调用 CMake；然后，CMake 在 objdir 中生成 Makefile，原始 Makefile 使用它们来进行构建。这可以确保人们不会意外地从源目录调用 CMake 并弄乱他们的存储库。与 MinGW 相结合，这个“CMake 三明治”提供了非常一致的跨平台构建体验！
So, judging purely by the criteria set forth in the question, the build system that seems like the best fit is probably waf - pure Python, provides support for C++ and other languages, general, powerful, not a DSL.
However, from my personal experience, I prefer CMake for C++ projects. (I tried CMake, SCons, and waf, and liked them in roughly that order). CMake is a general solution, but it has built-in support for C++ that makes it nicer than a more generic solution when you're actually doing C++.
CMake's build model for C++ is more declarative and less imperative, and thus, to me, easier to use. The CMake language syntax isn't great, but a declarative build with odd syntax beats an imperative build in Python. Of the three, CMake also seems to have the best support for "advanced" things like precompiled headers. Setting up precompiled headers reduced my rebuild time by about 70%.
Other pluses for CMake include decent documentation and a sizable community. Many open source libraries have CMake build files either in-tree or provided by the CMake community. There are major projects that already use CMake (OGRE comes to mind), and other major projects, like Boost and LLVM, are in the process of moving to CMake.
Part of the issue I found when experimenting with build systems is that I was trying to build a NPAPI plugin on OS X, and it turns out that very few build systems are set up to give XCode the exact combination of flags required to do so. CMake, recognizing that XCode is a complex and moving target, provides a hook for manually setting commands in generated XCode projects (and Visual Studio, I think). This is Very Smart as far as I'm concerned.
Whether you're building a library or an application may also determine which build system is best. Boost still uses a jam-based system, in part because it provides the most comprehensive support for managing build types that are more complex than "Debug" and "Release." Most boost libraries have five or six different versions, especially on Windows, anticipating people needing compatible libraries that link against different versions of the CRT.
I didn't have any problems with CMake on Windows, but of course your mileage may vary. There's a decent GUI for setting up build dependencies, though it's clunky to use for rebuilds. Luckily there's also a command-line client. What I've settled on so far is to have a thin wrapper Makefile that invokes CMake from an objdir; CMake then generates Makefiles in the objdir, and the original Makefile uses them to do the build. This ensures that people don't accidentally invoke CMake from the source directory and clutter up their repository. Combined with MinGW, this "CMake sandwich" provides a remarkably consistent cross-platform build experience!
当然，这取决于您的优先事项。如果您主要寻求易用性，那么至少有两个新的构建系统可以连接到文件系统，以与语言无关的方式自动跟踪依赖关系。
一种是 tup：
http://gittup.org/tup/
，另一种是 Fabricate：
http://code.google.com/p/fabricate/
似乎表现最好的一个，便携、成熟（也是我实际使用过的）就是tup。编写它的人甚至维护了一个玩具 Linux 发行版，其中所有内容都是 git 子模块，并且所有内容（包括内核）都是使用 tup 构建的。从我所读到的有关内核构建系统的内容来看，这是一项相当大的成就。
此外，Tup 还会清理旧目标和其他垃圾，并可以自动维护您的 .gitignore 文件。结果是，尝试目标的布局和名称变得微不足道，并且您可以自信地在 git 修订版之间跳转，而无需重建所有内容。它是用 C 语言编写的。
如果您了解 haskell 并且正在寻找非常高级的用例，请查看 shake：
http://community.haskell.org/~ndm/shake/
更新：我还没有尝试过，但是这个新的“buildsome”工具也挂钩到文件系统，并且受到 tup 的启发，所以也是相关：
https://github.com/ElastiLotem/buildsome
Of course that depends on what your priorities are. If you are looking primarily for ease of use, there are at least two new build systems that hook into the filesystem to automatically track dependencies in a language agnostic fashion.
One is tup:
http://gittup.org/tup/
and the other is fabricate:
http://code.google.com/p/fabricate/
The one that seems to be the best performing, portable, and mature (and the one I have actually used) is tup. The guy who wrote it even maintains a toy linux distro where everything is a git submodule, and everything (including the kernel) is build with tup. From what I've read about the kernel's build system, this is quite an accomplishment.
Also, Tup cleans up old targets and other cruft, and can automatically maintain your .gitignore files. The result is that it becomes trivial to experiment with the layout and names of your targets, and you can confidently jump between git revisions without rebuilding everything. It's written in C.
If you know haskell and are looking for something for very advanced use cases, check out shake:
http://community.haskell.org/~ndm/shake/
Update: I haven't tried it, but this new "buildsome" tool also hooks into the filesystem, and was inspired by tup, so is relevant:
https://github.com/ElastiLotem/buildsome
CMake
CMake
Selenium 项目正在转向 Rake，不是因为它是最好的，而是因为它处理多种语言的能力比 Rake 稍好一些所有其他构建工具都是跨平台的（用 Ruby 开发）。
所有构建工具都有其问题，人们学会忍受它们。在 JVM 上运行的东西往往非常适合构建应用程序，因此 Ant、Maven （我知道它很丑），常春藤，Rake
The Selenium project is moving over to Rake, not because its the best but because it handles multiple languages slightly better than all the other build tools and is cross platform (developed in Ruby).
All build tools have their issues and people learn to live with them. Something that runs on the JVM tends to be really good for building apps so Ant, Maven (i know its hideous), Ivy, Rake
Gradle 似乎符合上述所有标准。
它是一个结合了 Maven 和 Ant 优点的构建系统。对我来说，这是最好的。
Gradle seems to match all the criteria mentioned above.
It's a build system which took the best of Maven and Ant combined. To me, that's the best.
Final Builder 在 Windows 世界中众所周知
Final Builder is well known in Windows world
平滑构建 满足您的大多数要求。
披露：我是 smooth build 的作者。
smooth build matches most of your requirements.
disclosure: I'm the author of smooth build.