哪种构建系统对跨平台驱动程序、库和 GUI 构建提供最佳支持？
对于超过一百万行的多平台项目，使用 GNU 和 Microsoft 工具链为所有主流操作系统生成驱动程序、库、命令行工具、GUI 和操作系统安装包，构建系统的最佳选择是什么？
我们的源代码主要是C，带有Python、C#和GNU makefile，还有一点C++和bash。 它主要驻留在一个存储库中，但我们将源代码推送给各个第三方，所有第三方都有自己的源代码代码存储库。 还有一些人对保持快速构建感兴趣，这可能涉及拆分项目。
目前我们混合使用 GNU make、bash、python 和 Microsoft 的 DDKBUILD。 主要问题是我们在 make 之上维护一组复杂的脚本，并且更愿意使用第三方（最好是开源）工具，并且 cygwin 并没有被证明在 Windows 上是健壮的（例如 fork 并不总是可能的） ），并且我们当前的构建系统不会构建或安装工具链，因此容易受到工具链版本更改的影响。
What would be the best choice of build system for a more than one million line multi platform project, which produces drivers, libraries, command line tools, GUIs, and OS install packages for all the mainstream OSes, using both the GNU and Microsoft toolchains?
Our source code is mainly C, with Python, C# and GNU makefile, and a little C++ and bash. It resides mainly in one repository, but we push source code to various third parties all of whom have their source code code repositories. There is also some interest in keeping the build fast, which might involve splitting up the project.
Currently we use a mixture of GNU make, bash, python and Microsoft's DDKBUILD. The main problems are that we are maintaining a complex set of scripts on top of make and would prefer to use third party (preferably open source) tools, and that cygwin is not proving to be robust on Windows (e.g. fork isn't always possible), and that our current build system does not build or install the toolchain so is vulnerable to tool chain version changes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我投票支持 CMake，它是一个元构建工具，它真正从头开始重写 KDE4 构建系统，并使 KDE4 现在成为一个跨平台桌面，甚至可以在 WindowsCE 上运行！
CMake 是将 KDE4 移植到地球上任何操作系统的载体 - 通过使用相关工具链为大约 40 个操作系统生成 Makefile（或 Windows 情况下的 vcprojs）！
I vote for CMake, as a meta-building tool that really rewrite KDE4 build system from scratch -- and make KDE4 now a cross-platform desktop that even running on WindowsCE!
CMake is the carrier porting KDE4 to any OS on earth -- by generating Makefile( or vcprojs in Windows case) for about 40 OSes with relative toolchains!
JetBrains TeamCity 总体上运行良好，因此应该值得列入评估列表。
ThoughtWorks Cruise 也在同一空间。 虽然它是 v1，但它来自一个已经存在了一段时间的稳定版。
Team Foundation Server 没有任何东西可以让您将其排除在外，但开箱即用，它可能比我提到的其他两个更以 MS 商店为中心。
作为一般性评论，鉴于您所拥有的多样性水平，您肯定想尝试您想要使用的任何东西 - 仅仅因为某些东西被支持作为方框上的勾号并不意味着它会适合 oyu 正在寻找的东西。
JetBrains TeamCity works very well in general, so should be worth having on the eval list.
ThoughtWorks Cruise is also in the same space. While its v1, it comes from a stable that's been around for a while.
There's nothing about Team Foundation Server that would make necessarily count it out for your situation, but out of the box it might be more MS-shop centric that the other two I've mentioned.
As a general comment, with the level of variety you have, you definitely want to trial whatever it is you want to use - just because something is supported as a tick on the box doesnt mean its going to suit what oyu're looking for.
Dickson，
您的构建主要是整体式的，还是想单独构建一些库并将它们组装到更大的应用程序中？ 如果项目间的依赖性很重要，那么您的选择很快就会受到限制。 AnthillPro 做得很好，我认为TeamCity 有一些 Ivy 集成支持。 从您的说法来看，这听起来并不是绝对需要，但可能有助于加快构建速度。 我们已经看到许多团队有效地执行了这一策略。
由于您正在考虑跨平台（我假设是多台机器）构建，因此排除了 Hudson 之外的大多数开源工具。
构建服务器比较矩阵由我们在 Thoughtworks 的朋友在这里托管：confluence。 public.thoughtworks.org/display/CC/CI+Feature+Matrix
祝你好运。
Dickson,
Is your build mostly monolithic or do you want to build some libraries separately and assemble them into the larger application? If inter-project dependencies are a big deal, your choices become limited quickly. AnthillPro does it well, and I think TeamCity has some Ivy integration support. From what you're saying, it sounds like this is not an absolute need, but might be helpful in speeding the build. It's certainly a strategy that we've seen a number of teams execute effectively.
Since you're looking at cross-platform (I assume multiple machine) builds, most of the open source tools other than Hudson are ruled out.
A build server comparison matrix is hosted by our friends at Thoughtworks here: confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
Good luck.
您应该将 CMake 列入您要调查的替代方案列表中。 CMake 是一个元工具，即它生成您选择的构建工具（GNU make、Visual Studio 等）的输入。 我可以强烈推荐它。
You should have CMake on your list of alternatives to investigate. CMake is a meta-tool, i.e. it generates the input to the build-tool of your choice (GNU make, Visual Studio, etc.). I can recommend it strongly.
您可能想查看Cruise。 它基于 Java 构建，因此可以在任何支持 Java 的平台上运行。 您还可以在不同的计算机上拥有多个构建代理，这些代理可以在不同的平台上执行不同的任务。 Thoughtworks 仍在构建它，因此缺少一些功能，但它可能是一个不错的选择，因为您正在寻找真正的跨平台功能。
You may want to look at Cruise. It is built on Java so it will run on any platform that supports that. You can also have multiple build agents on different machines that can perform the different tasks on the different platforms. Thoughtworks is still building it out so some of the functionality is lacking, but it may be a a good option since you are looking for true cross-platform capabilities.
SCons 是一个用 Python 实现的跨平台构建系统。 我们用它在三个平台上构建我们的代码。 它可以自动检测您的构建工具，但您也可以将任意 Python 代码放入构建脚本中。 它还允许您将环境设置与项目结构的描述分开，这是在不同环境中重用 buidl 脚本的一个很棒的功能。 除了直接构建项目外，它还可以生成 Visual Studio 项目文件。
SCons is a cross-platform build system implemented in Python. We use it to build our code on three platforms. It can automatically detect your build tools but you can also put arbitrary Python code in your build script. It also lets you separate your environment setup from description of your project structure, a great feature for reuse of your buidl scripts in different environments. Besides building your project directly, it can also generate Visual Studio project files.