构建脚本的优点是什么？

在我的大部分编程生涯中，我都在与我一起使用的IDE中使用“ build / compile / run”命令来生成可运行的程序。这是一个按钮，非常简单。但是，随着我对不同语言和框架的更多了解，我越来越多地谈论“构建脚本”（ANT，Maven，Gradle等）来运行项目。我对这些的理解是，它们是给编译器/链接器/ magical-program-maker的指令，用于指定配置详细信息-细节。

我记得在学校时曾写过makefile，但是那时我并没有看到任何特殊的优势（我们只在Unix终端中使用它们，因为在该终端中没有带有“构建”按钮的IDE）。除此之外，我在这里还看到了其他问题，这些问题讨论了构建脚本不仅可以创建程序，还可以做更多的事情- 它们可以运行单元测试以及安全的资源，而与主机无关。

我不能忘记构建脚本对于作为开发人员来说很重要的感觉，但是我想要一个有意义的解释。为什么要使用/编写构建脚本？

Build Script和Build Server的职责讨论了它在更大范围内的作用。我正在寻找构建脚本相对于IDE的“构建/运行”命令或类似的简单方法所提供的特定优势。

自动化。

当您进行开发时，只有在最简单的项目中，默认的“构建”按钮才可以执行您需要执行的所有操作。您可能需要使用API​​创建WS，生成文档，与外部资源链接，将更改部署到服务器等。某些IDE允许您通过添加额外的步骤或构建器来自定义构建过程，但这仅意味着您已经通过IDE商品生成构建脚本。

但是开发系统不仅是编写代码。涉及多个步骤。IDE独立脚本可以自动执行，这意味着：

• 当您提交对版本控制的更改时，服务器可以自动启动新的构建。这将确保您不会忘记提交构建所需的任何内容。

• 同样，在完成构建后，可以自动运行测试以查看是否损坏了某些内容。

• 现在，该组织的其他成员（QA，sysadmins）拥有一个内置的产品，

  a）仅从控制版本即可完美再现。

  b）是所有这些人共有的。

即使当我作为一个人的团队工作时，我也为此使用了脚本。开发修补程序后，我将致力于SVN，将SVN导出回另一个目录中，并使用构建脚本生成解决方案，然后将其提交到Preproduction系统，再到Production。如果几个星期后（我的本地代码库已更改）有人抱怨一个错误，我将确切知道我必须检出哪个SVN版本才能正确调试系统。

像代码一样，构建脚本由计算机执行。计算机非常擅长遵循一组说明。实际上，（在自我修改代码之外），计算机将在给定相同输入的情况下以完全相同的方式执行相同的指令序列。这提供了只有计算机才能匹配的一致性级别。

相比之下，在执行以下步骤时，我们充水的皮袋简直是卑鄙的。那个讨厌的分析大脑倾向于质疑它遇到的一切。“哦...我不需要那个”，或“我真的要使用这个标志吗？恩...我只是忽略它。” 此外，我们有一种自满的趋势。完成几次操作后，我们开始相信我们已经了解了说明，而不必阅读说明表。

摘自《实用程序员》：

另外，我们要确保项目的一致性和可重复性。手动程序可以使一致性保持变化；无法保证可重复性，尤其是在过程的各个方面可以由不同的人解释的情况下。

此外，我们在执行指令方面总是比较迟钝（与计算机相比）。在具有数百个文件和配置的大型项目中，手动执行构建过程中的所有步骤将花费数年。

我给你一个真实的例子。我当时正在使用一些嵌入式软件，其中大多数代码是在几个不同的硬件平台上共享的。每个平台具有不同的硬件，但是大多数软件是相同的。但是，每种硬件只有很少的一部分。理想情况下，将公共部分放置在库中并链接到每个版本中。但是，这些常见的部分无法编译到共享库中。必须使用每种不同的配置进行编译。

首先，我手动编译了每个配置。只需几秒钟即可在配置之间进行切换，并不是什么大麻烦。在项目结束时，在代码的共享部分发现了一个严重的缺陷，在该缺陷中，设备实际上将接管通信总线。这真是糟糕！特别糟糕。我在代码中找到该错误，对其进行了修复，然后重新编译了每个版本。除了一个。在构建过程中，我分心了，忘了一个。释放了二进制文件，构建了机器，一天后，我接到一个电话，说机器停止响应。我检查了一下，发现设备锁定了总线。“但是我修复了这个错误！”。

我可能已经修复了它，但是它从来没有在那块板上找到方法。为什么？因为我没有一个自动构建过程即可一键构建每个单独的版本。

如果您只是想做的事情<compiler> **/*.<extension>，构建脚本将毫无用处（尽管有人会争辩说，如果您Makefile在项目中看到，就知道可以使用来构建它make）。问题是-非平凡的项目通常需要更多的资源-至少，您通常需要添加库并（随着项目的成熟）配置构建参数。

IDE通常至少是可配置的-但是现在构建过程依赖于IDE特定的选项。如果您使用的是Eclipse，则Alice更喜欢NetBeans，而Bob则想使用IntelliJ IDEA，那么您将无法共享配置，并且当您中的一个将更改推送到源代码管理时，他们需要手动编辑IDE创建的配置其他开发人员的文件，或通知其他开发人员以便他们自己完成（这意味着在某些IDE的IDE配置错误的地方会有提交...）。

您还需要弄清楚如何在团队使用的每个IDE中进行更改，以及其中的一个不支持该特定设置的情况...

现在，此问题与文化有关，您的开发人员可能会发现不必选择IDE就可以接受。但是，具有IDE经验的开发人员在使用它时通常会更快乐，更高效，并且文本编辑器用户倾向于对自己喜欢的工具抱有虔诚的热情，因此这是您想要给开发人员自由的地方之一-并且构建系统使您可以做到这一点。有些人可能对构建系统有偏好，但是它不像IDE /编辑器偏好那么狂...

即使让所有开发人员都使用同一IDE，也很幸运，可以说服构建服务器使用它。

现在，这是针对简单的构建过程自定义，IDE倾向于为其提供漂亮的GUI。如果您需要更复杂的内容（例如在编译之前进行预处理/自动生成源文件），通常必须在IDE的配置中的一些基本文本区域中编写预构建脚本。您仍然必须对哪个构建系统进行编码，但是您可以在编写代码的实际编辑器中进行编码，更重要的是：构建系统的框架本身通常为组织这些脚本提供一些支持。

最后-构建系统不仅仅可以构建项目，还可以为团队中每个人可能需要执行的其他任务编程。例如，在Ruby on Rails中，存在用于运行数据库迁移，清理临时文件等的构建系统任务。将这些任务放入构建系统可确保团队中的每个人都能一致地完成它们。

许多IDE只是打包用于构建内容的命令，然后生成脚本并调用它！

例如，在Visual Studio中，您可以在“命令行”框中看到C ++编译的命令行参数。如果仔细查看构建输出，将会看到包含用于运行编译的构建脚本的临时文件。

如今，所有这些都是MSBuild，但是仍然可以直接由IDE运行。

因此，使用命令行的原因是，您直接去了源代码，而跳过了中间人，一个中间人，该中间人可能已被更新，或者需要在无头服务器上不需要或不需要的依赖项堆。充当您的持续集成（CI）服务器。

另外，您的脚本比通常针对开发人员设计的步骤要多。例如，在构建之后，您可能希望将二进制文件打包并复制到一个特殊位置，或者创建一个安装程序包，或者在其上运行文档工具。CI服务器执行了许多不同的任务，这些任务在开发人员机器上是毫无意义的，因此，尽管您可以创建一个IDE项目来执行所有这些步骤，但您必须维护其中的两个步骤-一个用于开发人员的项目，另一个用于构建的项目。对于开发人员项目，某些构建任务（例如静态分析）可能会花费很长时间。

简而言之，它很容易-创建一个脚本来完成您想要的所有事情，并且可以在命令行或构建服务器配置上快速，轻松地启动它。

make

比起记住和键入要容易得多

gcc -o myapp -I/include/this/dir -I/include/here/as/well -I/dont/forget/this/one src/myapp.c src/myapp.h src/things/*.c src/things/*.h

项目可能具有非常复杂的编译命令。构建脚本还具有仅重新编译已更改内容的功能。如果您要进行干净的构建，

make clean

一旦正确设置，比试图记住每个可能产生中间文件的位置更容易且更可靠。

当然，如果使用IDE，单击构建或清除按钮也很容易。但是，要自动将光标移动到屏幕上的特定位置要困难得多，尤其是当窗口移动时该位置可能会移动时，要比自动执行简单的文本命令要困难得多。

你还会怎么做？唯一的其他方法是指定一个长命令行命令。

另一个原因是makefile允许增量编译，这大大加快了编译时间。

Makefile也可以使构建过程跨平台。CMake基于平台生成不同的构建脚本。

编辑：

使用IDE，您将被束缚于一种特定的工作方式。许多人使用vim或emacs，尽管它们没有许多类似IDE的功能。他们之所以这样做，是因为他们想要这些编辑器提供的功能。对于不使用IDE的用户，必须使用构建脚本。

即使对于使用IDE的用户，您可能也想真正知道发生了什么，因此构建脚本为您提供了GUI方法所没有的实施细节。

IDE本身也经常在内部使用构建脚本。运行按钮只是运行make命令的另一种方式。

上面的答案涵盖了很多基础，但是我想添加的一个真实示例（由于没有因果关系而无法添加为注释）来自Android编程。

我是一个专业的Android / iOS版/ Windows Phone的开发，我使用谷歌服务API（主要是谷歌地图），一个不少。

在Android中，这些服务要求我向开发人员控制台添加keystore或一种类型的开发人员ID文件，该文件告诉Google我是谁。如果我的应用是使用其他密钥库编译的，则该应用的“ Google地图”部分将无法正常工作。

我没有在开发者控制台中添加和管理十二个密钥库，而实际上只能使用其中的一个来更新应用程序，而是将这个密钥库包含在我们的安全存储库中，并使用Gradle告诉Android Studio在为其构建时确切使用哪个密钥库。 “调试”或“发布”。现在，我只需要在我的Google开发人员控制台中添加两个密钥库，一个用于“调试”，一个用于“发行”，我的所有团队成员都可以克隆该存储库并直接进行开发，而无需进入开发人员控制台并添加其特定密钥库的SHA哈希，或更糟糕的是，让我对其进行管理。这具有为每个团队成员提供签名密钥库副本的额外好处，这意味着如果我不在办公室并且计划了更新，则团队成员只需遵循很短的说明列表即可推送更新。

这样的构建自动化可保持构建的一致性，并通过减少新开发者，新机器或必须对机器进行重新映像时的设置时间来减少技术负担。

构建脚本的优点：

• 更改看起来像代码（例如，在git diff命令中），而不像对话框中不同的选中选项

• 创建比简单构建更多的输出

在以前的一些项目中，我使用了构建脚本来：

• 生成项目文档（基于Doxygen）
• 建立
• 运行单元测试
• 生成单元测试覆盖率报告
• 将二进制文件打包到发行档案中
• 生成内部发行说明（基于“ git log”消息）
• 自动化测试

通常，您可以通过自动方式调用“构建”按钮（例如，Visual Studio接受命令行参数）。人们只要需要构建按钮无法提供的内容，就可以编写构建脚本。

例如，大多数IDE仅允许您一次构建一个平台。或一次只使用一种语言。然后，您将对内置输出进行处理：您的IDE可以将它们全部汇总到安装包中吗？