每次从源代码编译某些东西时，都会经历相同的 3 个步骤：
$ ./configure
$ make
$ make install
我明白，将安装过程分成不同的步骤是有意义的，但我不明白，为什么这个星球上的每个编码人员都必须一遍又一遍地编写相同的三个命令，只是为了得到一个任务完成。从我的角度来看，将./install.sh 脚本与包含以下文本的源代码一起自动交付是完全有意义的：
#!/bin/sh
./configure
make
make install
为什么人们会分开执行这 3 个步骤？
【问题讨论】：
标签： unix makefile configure make-install
因为每一步都做不同的事情
./configure
这个脚本有很多你应该改变的选项。喜欢--prefix 或--with-dir=/foo。这意味着每个系统都有不同的配置。 ./configure 还会检查是否缺少应该安装的库。此处有任何问题会导致无法构建您的应用程序。这就是为什么发行版的软件包安装在不同的地方，因为每个发行版都认为将某些库和文件安装到某些目录会更好。据说运行./configure，但实际上您应该始终更改它。
例如看看the Arch Linux packages site。在这里，您将看到任何包都使用不同的配置参数（假设它们使用构建系统的自动工具）。
make
默认情况下这实际上是make all。每个品牌都有不同的行动要做。有些是在构建，有些是在构建后进行测试，有些是从外部 SCM 存储库中检出。通常你不必提供任何参数，但有些包再次以不同的方式执行它们。
make install
这会将软件包安装在 configure 指定的位置。如果你愿意，你可以指定./configure 指向你的主目录。但是，许多配置选项都指向/usr 或/usr/local。这意味着你必须实际使用sudo make install，因为只有 root 才能将文件复制到 /usr 和 /usr/local。
现在您看到每个步骤都是下一步的先决条件。每一步都是为使事情顺利进行的准备工作。发行版使用这个比喻来构建包（如 RPM、deb 等）。
在这里您会看到每个步骤实际上是不同的状态。这就是为什么包管理器有不同的包装器。下面是一个包装器示例，可让您一步构建整个包。但请记住，每个应用程序都有不同的包装器（实际上这些包装器有一个名称，例如 spec、PKGBUILD 等）：
def setup:
... #use ./configure if autotools is used
def build:
... #use make if autotools is used
def install:
... #use make all if autotools is used
这里可以使用自动工具，即./configure、make 和make install。但另一个可以使用 SCons、Python 相关设置或其他不同的东西。
如您所见，拆分每个状态使维护和部署变得更加容易，尤其是对于包维护者和发行版。
【讨论】：
install 依赖于all 因此make install 将调用make all
make install 只需将各种资源安装到预定义的位置。如果您只关心可执行文件，则可以使用构建目录中的可执行文件并将构建目录添加到您的 PATH。
首先，它应该是./configure && make && make install，因为每个都取决于前者的成功。部分原因是进化，部分原因是开发工作流程的便利性。
最初，大多数Makefiles 只包含编译程序的命令，安装留给用户。一条额外的规则允许make install 将编译后的输出放置在可能正确的位置；您可能仍然有很多充分的理由不想这样做，包括不是系统管理员，根本不想安装它。此外，如果我正在开发软件，我可能不想安装它。我想进行一些更改并测试我目录中的版本。如果我将有多个版本，这将变得更加突出。
./configure 会检测环境中可用的和/或用户希望确定如何构建软件的内容。这不是需要经常更改的东西，而且通常需要一些时间。同样，如果我是一名开发人员，不值得花时间不断地重新配置。更重要的是，由于make 使用时间戳来重建模块，如果我重新运行configure，标志可能会改变，现在我的构建中的一些组件将使用一组标志进行编译，而其他组件将使用一组不同的标志进行编译可能导致不同的、不兼容的行为的标志。只要我不重新运行configure，我就知道我的编译环境保持不变，即使我更改了我的源代码。如果我重新运行configure，我应该首先make clean，以删除任何已构建的源以确保统一构建。
三个命令连续运行的唯一情况是用户安装程序或构建软件包时（例如，Debian 的 debuild 或 RedHat 的 rpmbuild）。并且假设可以给包一个普通的configure，这通常不是打包的情况，至少需要--prefix=/usr。在做make install 部分时，pacakgers 喜欢处理假根。由于有很多例外，因此将./configure && make && make install 设置为规则对于很多经常这样做的人来说会很不方便！
【讨论】：
&&的建议！
configure 如果发现缺少依赖项，可能会失败。
make 运行默认目标，即 Makefile 中列出的第一个目标。这个目标通常是all，但并非总是如此。所以你只能make all install，如果你知道那是目标。
所以...
#!/bin/sh
if ./configure $*; then
if make; then
make install
fi
fi
或：
./configure $* && ./make && ./make install
之所以包含$*，是因为人们经常需要为configure 提供选项。
但是为什么不让人们自己做呢？真的有这么大的胜利吗？
【讨论】：
configure 是 GNU Automake 工具包的一部分，它是 Make 的一个附加组件。 Make 已经存在了很多很多年，并且做得很好。也就是说，人们已经想出了其他方法来处理制作过程。 Ant 和 cmake 有他们的追随者。但构建过程的各个部分（如配置、构建和安装）仍然是单独的命令。
首先，./configure 并不总能找到它需要的所有东西，或者在其他情况下，它会找到它需要的所有东西，但不是它可以使用的所有东西。在这种情况下，您会想知道它（并且您的 ./install.sh 脚本无论如何都会失败！）从我的角度来看，具有意外后果的非失败的经典示例是编译大型应用程序，如 ffmpeg 或 mplayer。如果它们可用，它们将使用库，但如果它们不可用，则无论如何都会编译，从而禁用某些选项。问题是你后来发现它是在不支持某种格式的情况下编译的，因此需要你回去重做。
./configure 以交互方式做的另一件事是让您可以选择自定义应用程序在系统上的安装位置。不同的发行版/环境有不同的约定，您可能希望遵守系统上的约定。此外，您可能希望在本地安装它（仅供您自己使用）。传统上 ./configure 和 make 步骤不以 root 身份运行，而 make install（除非它是为您自己安装的）必须以 root 身份运行。
特定发行版通常会提供脚本，这些脚本以对发行版敏感的方式执行此 ./install.sh 功能 - 例如，source RPMs + spec file + rpmbuild 或 slackbuilds。
（脚注：话虽如此，我同意 ./configure; make; make install; 会变得非常乏味。）
【讨论】：