为什么要使用构建系统而不是IDE中包含的构建系统？

Question

我听说过不止一个人说如果你的构建过程点击了构建按钮,那么你的构建过程就会被破坏.这常常伴随着建议使用之类的东西make,cmake,nmake,MSBuild,等究竟是什么这些工具提供证明有理由手动维护单独的配置文件？

编辑:我最感兴趣的是那些适用于开发~20k系列C++项目的开发人员的答案,但我也对一般情况感兴趣.

编辑2:看起来这个问题没有一个好的答案,所以我继续前进并使它成为CW.回应那些谈论持续集成的人,是的,当你有很多开发人员参与CI很好的项目时,我完全理解.但是,这是CI的优势,而不是维护单独的构建脚本.它们是正交的:例如,Team Foundation Build是一个CI解决方案,它使用Visual Studio的项目文件作为其配置.

Answer 1

除了其他人已经解决的持续集成需求之外,您可能还希望自动化构建过程的其他一些方面.也许这就像在生产版本中增加版本号,运行单元测试,重置和验证测试环境,或运行FxCop或自动执行代码审查以实现企业标准合规性的自定义脚本一样简单.除了简单的代码编译之外,构建脚本只是一种自动化方法.但是,大多数这类事情也可以通过几乎每个现代IDE允许您设置的预编译/后编译操作来完成.

说实话,除非你有许多开发人员提交你的源代码控制系统,或者有很多系统或应用程序依赖于共享库并且需要执行CI,否则使用构建脚本与简单的替代方案相比可能是过度的.但是,如果你是在前述的那些情况,从源头控制拉并不会自动构建应该是你的团队的库的重要组成部分专用构建服务器,并设置一个最简单的方法之一是使用make,MSBuild,Ant,等.

Answer 2

我很惊讶没有人提到使用构建系统的原因之一是灵活性。过去，我还使用 IDE 的内置构建系统来编译我的代码。然而，当我使用的 IDE 停止使用时，我遇到了一个大问题。我编译代码的能力与我的 IDE 相关，因此我被迫重新构建整个构建系统。不过，第二次我没有犯同样的错误。我通过 makefile 实现了构建系统，这样我就可以随意切换编译器和 IDE，而无需再次重新实现构建系统。

我在工作中也遇到过类似的问题。我们有一个内部实用程序，它是作为 Visual Studio 项目构建的。这是一个相当简单的实用程序，多年来不需要更新，但我们最近发现了一个需要修复的罕见错误。令我们沮丧的是，我们发现该实用程序是使用比我们当前版本早 5-6 个版本的 Visual Studio 构建的。新的VS无法正确读取旧版本的项目文件，我们不得不从头开始重新创建项目。尽管我们仍然使用相同的 IDE，但版本差异破坏了我们的构建系统。

当您使用单独的构建系统时，您可以完全控制它。更改 IDE 或 IDE 版本不会破坏任何内容。如果您的构建系统基于像 的开源工具make，您也不必担心您的构建工具被停止或放弃，因为如果需要，您始终可以从源代码重新构建它们（加上修复错误）。依赖 IDE 的构建系统会引入单点故障（尤其是在像 Visual Studio 这样也集成了编译器的平台上），在我看来，这足以成为我将构建系统和 IDE 分开的理由。

在更哲学的层面上，我坚信自动化处理你不理解的东西并不是一件好事。使用自动化来提高自己的工作效率是件好事，但前提是您对幕后发生的事情有深入的了解（这样当自动化中断时您就不会陷入困境，如果没有其他原因的话）。当我第一次开始编程时，我使用了 IDE 的内置构建系统，因为它既简单又自动。后来我开始更加意识到，当我单击“编译”按钮时，我并没有真正理解发生了什么。我做了一些阅读，并开始从头开始编写一个简单的构建脚本，将我的输出与 IDE 构建系统的输出进行比较。一段时间后，我意识到我现在有能力通过 IDE 完成各种困难或不可能的事情。通过自定义编译器的命令行选项（超出 IDE 提供的选项），我能够生成更小、速度稍快的输出。更重要的是，通过真正了解从编写代码一直到生成机器语言的整个开发过程，我成为了一名更好的程序员。了解和控制整个端到端流程使我能够根据我当前正在进行的任何项目的需求来优化和定制所有流程。