您想要简化的制作吗？ 在这种情况下，您需要找一个非常熟悉 make 的人来创建一系列 (M|m)akefiles 以简化您的问题。
或者你想看看底层技术吗？ 我们是否想要强制执行一种内置于代码设计中并在代码设计中强制执行的按合同设计类型架构？ 或者可能是语言本身，例如 Ada 及其规范（接口）和主体（实现）的概念？
你追求的哪个方向肯定会影响这样一个问题的潜在结果？
基本上，仅使用那些真正改变的组件构建系统的新方法与采用在设计中内置此类机制的新技术不同。
抱歉，这不是直接答案。 只是想让你评估一下你想要走哪条路。
干杯，
罗布
I'm not sure if you are asking the correct question here.
Are you after a simplified make? In which case, you need to get someone who is very familiar with make to create a series of (M|m)akefiles that will simplify your problem.
Or are you wanting to look at the underlying technology? Are we wanting to enforce a design-by-contract type architecture which is built in to, and enforced in, the code design? Or possibly, the language itself, e.g. Ada and its concept of specs (interfaces) and bodies (implementations)?
Which direction you are after will definitely affect the potential results of such a question?
Basically, new ways of building systems from only those components that have really changed versus adoption of new technologies that have such mechanisms built in by design.
Sorry it's not a direct answer. Just wanted to try and get you to evaluate which path you wanted to head down.
It has a GUI which shows the dependency graph with color-coded boxes for jobs and ovals for files. When the number of jobs and files gets high, a GUI-based tool like FlowTracer is pretty much essential.
The initial setup cost is higher than Make. There's a learning curve for setting up your first flow using it. After that, it gets quicker.
这在某种程度上取决于您想要做什么。 如果您想要的只是 make 风格的目标依赖项和命令调用，那么 Make 实际上是完成该任务的更好工具之一。 :-) Rake 非常好，但对于一些简单的情况可能会很笨拙。 Ant 当然是冗长的城市，但它对构建类似 Java 的语言（包括 Scala 和 Groovy）有更好的支持。 此外，Ant 随处可用。 这是我使用它的主要原因。 因为它在 Windows 上一致地工作，所以它实际上比 Make 更具跨平台性。
It sort of depends on what you're trying to do. If all you want is make-style target dependencies and command invocation, then Make is actually one of the better tools for the task. :-) Rake is very nice, but can be clumsy for some simple cases. Ant is of course verbosity city, but it has better support for building Java-like languages (Scala and Groovy included). Also, Ant is available everywhere. That's the main reason I use it. Because it works consistently on Windows, it's actually even more cross-platform than Make.
If you want dependency management for Java-like libraries, Maven is the canonical choice, but I personally like Buildr a lot better. It's faster and much easier to customize (it's based on Rake). Unfortunately, it isn't quite as ubiquitous as Maven just yet.
在考虑了一堆替代方案之后，我仍然更喜欢 make。 当您通过编译器或 fastdep 之类的东西自动生成依赖项时，就没有什么可做的了。 特别是，我不希望我的构建脚本与实现语言绑定，并且当有更多可读的替代方案可用时，我不喜欢用 XML 编写内容。 公开通用语言的工具虽然有优点，但另一种解释语言却没有（据我所知）。
I still prefer make after having considered a bunch of the alternatives. When you auto-generated dependencies either via the compiler or something like fastdep there is not much left to do. In particular I do not want my build script to be tied to the implementation language, and I don't like writing stuff in XML when more readable alternatives are available. A tool that expose a general purpose language has merit though, but yet another interpreted language does not (afaik).
Be aware of the ninja build tool (v1.8.2 Sept 2017) which is influenced by tup and redo.
The build file generator cmake (e.g. for Unix Makefiles, Visual Studio, XCode, Eclipse CDT, ...) can also generate ninja build files since version 2.8.8 (April 2012) and, afaik, ninja is now even the default build tool used by cmake.
It is supposed to outperform the make tool (better dependency tracking and is also parallelized).
cmake is an already well-established tool. You can always choose later the build tool without modifying your configuration files. So if a better build is developed in the future which will be supported by cmake you can switch to it conveniently.
Note that for c/c++ improving compilation time is sometimes limited because of headers included through the preprocessor (in particular when using header-only libs, for instance boost & eigen) which hopefully will be replaced by the proposal of modules (in a technical review of c++11 or eventually in c++1y). Check out this presentation for details on this issue.
It's the build system used for VTK (among other things), which is a C++ library with cross-platform Python, Tcl, and Java bindings. I think it's probably the least complicated thing you'll find with that many capabilities.
You could always try the standard autotools. Automake files are pretty easy to put together if you're only running on Unix and if you stick to C/C++. Integration is more complicated, and autotools is far from the simplest system ever.
Some of the GNOME projects have been migrating to waf.
It's Python-based, like Scons, but also standalone -- so rather than require other developers to have your favorite build tool installed, you just copy the standalone build script into your project.
发布评论
评论（12）
我不确定你在这里问的问题是否正确。
您想要简化的制作吗？ 在这种情况下，您需要找一个非常熟悉 make 的人来创建一系列 (M|m)akefiles 以简化您的问题。
或者你想看看底层技术吗？ 我们是否想要强制执行一种内置于代码设计中并在代码设计中强制执行的按合同设计类型架构？ 或者可能是语言本身，例如 Ada 及其规范（接口）和主体（实现）的概念？
你追求的哪个方向肯定会影响这样一个问题的潜在结果？
基本上，仅使用那些真正改变的组件构建系统的新方法与采用在设计中内置此类机制的新技术不同。
抱歉，这不是直接答案。 只是想让你评估一下你想要走哪条路。
干杯，
罗布
I'm not sure if you are asking the correct question here.
Are you after a simplified make? In which case, you need to get someone who is very familiar with make to create a series of (M|m)akefiles that will simplify your problem.
Or are you wanting to look at the underlying technology? Are we wanting to enforce a design-by-contract type architecture which is built in to, and enforced in, the code design? Or possibly, the language itself, e.g. Ada and its concept of specs (interfaces) and bodies (implementations)?
Which direction you are after will definitely affect the potential results of such a question?
Basically, new ways of building systems from only those components that have really changed versus adoption of new technologies that have such mechanisms built in by design.
Sorry it's not a direct answer. Just wanted to try and get you to evaluate which path you wanted to head down.
cheers,
Rob
Ruby 的 make 系统称为 rake： http://rake.rubyforge.org/
看起来很有前途。
总是有 Ant：http://ant.apache.org，我个人觉得它很可怕。 然而，它是 Java 开发事实上的标准。
Ruby's make system is called rake: http://rake.rubyforge.org/
Looks quite promising.
There's always Ant: http://ant.apache.org, which I personally find horrendous. It's the de-facto standard for Java development, however.
RTDA 的 FlowTracer 是我在大型环境（数万个作业）中看到的另一个不错的选择：http://www.rtda.com/flowtracer-design-flow-infrastruct-software
它有一个 GUI，显示依赖关系图，其中带有作业的颜色编码框和文件的椭圆形。 当作业和文件的数量变多时，像 FlowTracer 这样基于 GUI 的工具就非常必要了。
初始设置成本高于Make。 使用它设置第一个流程有一个学习曲线。 之后，它会变得更快。
FlowTracer from RTDA is another good choice that I have seen used commercially in a large scale environment (tens of thousands of jobs): http://www.rtda.com/flowtracer-design-flow-infrastructure-software
It has a GUI which shows the dependency graph with color-coded boxes for jobs and ovals for files. When the number of jobs and files gets high, a GUI-based tool like FlowTracer is pretty much essential.
The initial setup cost is higher than Make. There's a learning curve for setting up your first flow using it. After that, it gets quicker.
我编写了一个名为 sake 的工具，它试图使编写类似于 makefile 的内容变得非常容易阅读和编写。
I wrote a tool called sake that tried to make writing makefile-like things very easy to read and write.
这在某种程度上取决于您想要做什么。 如果您想要的只是 make 风格的目标依赖项和命令调用，那么 Make 实际上是完成该任务的更好工具之一。 :-) Rake 非常好，但对于一些简单的情况可能会很笨拙。 Ant 当然是冗长的城市，但它对构建类似 Java 的语言（包括 Scala 和 Groovy）有更好的支持。 此外，Ant 随处可用。 这是我使用它的主要原因。 因为它在 Windows 上一致地工作，所以它实际上比 Make 更具跨平台性。
如果您想要类似 Java 的库的依赖管理，Maven 是规范的选择，但我个人更喜欢 Buildr。 它更快、更容易定制（它基于 Rake）。 不幸的是，它还没有像 Maven 那样普遍。
It sort of depends on what you're trying to do. If all you want is make-style target dependencies and command invocation, then Make is actually one of the better tools for the task. :-) Rake is very nice, but can be clumsy for some simple cases. Ant is of course verbosity city, but it has better support for building Java-like languages (Scala and Groovy included). Also, Ant is available everywhere. That's the main reason I use it. Because it works consistently on Windows, it's actually even more cross-platform than Make.
If you want dependency management for Java-like libraries, Maven is the canonical choice, but I personally like Buildr a lot better. It's faster and much easier to customize (it's based on Rake). Unfortunately, it isn't quite as ubiquitous as Maven just yet.
在考虑了一堆替代方案之后，我仍然更喜欢 make。 当您通过编译器或 fastdep 之类的东西自动生成依赖项时，就没有什么可做的了。 特别是，我不希望我的构建脚本与实现语言绑定，并且当有更多可读的替代方案可用时，我不喜欢用 XML 编写内容。 公开通用语言的工具虽然有优点，但另一种解释语言却没有（据我所知）。
I still prefer make after having considered a bunch of the alternatives. When you auto-generated dependencies either via the compiler or something like fastdep there is not much left to do. In particular I do not want my build script to be tied to the implementation language, and I don't like writing stuff in XML when more readable alternatives are available. A tool that expose a general purpose language has merit though, but yet another interpreted language does not (afaik).
请注意
ninja构建工具（v1.8.2 Sept 2017）受tup和重做。构建文件生成器
cmake（例如，用于 Unix Makefiles、Visual Studio、XCode、Eclipse CDT、 ...) 从版本 2.8.8（2012 年 4 月）开始，还可以生成ninja构建文件，而且，据我所知，ninja现在甚至是使用的默认构建工具.cmake.它应该优于
make工具（更好的依赖性跟踪并且也是并行化的）。cmake是一个已经完善的工具。 您以后随时可以选择构建工具，而无需修改配置文件。 因此，如果将来开发出更好的版本，并由cmake支持，您可以方便地切换到它。请注意，对于 c/c++，改进编译时间有时会受到限制，因为通过预处理器包含标头（特别是在使用仅标头库时，例如 boost 和 eigen) 希望将被 模块（在 c++11 的技术审查中或最终在 c++1y 中）。 查看此演示文稿有关此问题的详细信息。
Be aware of the
ninjabuild tool (v1.8.2 Sept 2017) which is influenced bytupandredo.The build file generator
cmake(e.g. for Unix Makefiles, Visual Studio, XCode, Eclipse CDT, ...) can also generateninjabuild files since version 2.8.8 (April 2012) and, afaik,ninjais now even the default build tool used bycmake.It is supposed to outperform the
maketool (better dependency tracking and is also parallelized).cmakeis an already well-established tool. You can always choose later the build tool without modifying your configuration files. So if a better build is developed in the future which will be supported bycmakeyou can switch to it conveniently.Note that for c/c++ improving compilation time is sometimes limited because of headers included through the preprocessor (in particular when using header-only libs, for instance boost & eigen) which hopefully will be replaced by the proposal of modules (in a technical review of c++11 or eventually in c++1y). Check out this presentation for details on this issue.
我有很多朋友非常信赖 CMake 进行跨平台开发：
http://www.cmake.org/
它是用于 VTK （除其他外）的构建系统，它是一个跨平台的 C++ 库Python、Tcl 和 Java 绑定。 我认为这可能是您能找到的具有这么多功能的最简单的东西。
您始终可以尝试标准的autotools。 如果您只在 Unix 上运行并且坚持使用 C/C++，则 Automake 文件非常容易组合在一起。 集成更加复杂，并且 autotools 远非最简单的系统。
I have a lot of friends who swear by CMake for cross-platform development:
http://www.cmake.org/
It's the build system used for VTK (among other things), which is a C++ library with cross-platform Python, Tcl, and Java bindings. I think it's probably the least complicated thing you'll find with that many capabilities.
You could always try the standard autotools. Automake files are pretty easy to put together if you're only running on Unix and if you stick to C/C++. Integration is more complicated, and autotools is far from the simplest system ever.
doit 是一个Python工具。 它基于构建工具的概念，但更通用。
doit is a python tool. It is based in the concepts of build-tools but more generic.
一些 GNOME 项目已迁移到 waf。
它是基于 Python 的，就像 Scons 一样，但也是独立的——因此不需要其他开发人员安装您最喜欢的构建工具，您只需将独立构建脚本复制到您的项目中即可。
Some of the GNOME projects have been migrating to waf.
It's Python-based, like Scons, but also standalone -- so rather than require other developers to have your favorite build tool installed, you just copy the standalone build script into your project.
我建议使用 Rake。 这是我发现的最简单的工具。
不过，如果您不喜欢 Ruby，我使用过的其他好工具有：
I recommend using Rake. It's the easiest tool I've found.
Other good tools I've used, though, if Ruby's not your thing, are:
查看SCons。 例如 Doom 3 和 Blender 就使用了它。
check out SCons. For example Doom 3 and Blender make uses of it.