为啥linux下要configure然后make make install

Posted 2023-05-12

参考技术A configure
Linux
平台有各种不同的配置，安装时需要通过
configure 来确定，如：编译器用的是
cc
还是
gcc、不同库文件所在目录等。执行
configure
后会生成
Makefile，Makefile
规定了用什么编译器、编译参数等信息。
make
根据
Makefile
中规定的内容进行编译，生成的可执行文件放在当前目录或某个子目录。
make
install
将
make
生成的文件安装到系统目录中，如
/usr/bin，这一步需要
root
权限，所以通常得用
sudo make
install。如果没有这一步，在命令行中输入程序名字不能启动相应程序。

为啥总是 ./configure;制作;进行安装；作为3个单独的步骤？

【中文标题】为啥总是 ./configure;制作;进行安装；作为3个单独的步骤？

【英文标题】：Why always ./configure; make; make install; as 3 separate steps?为什么总是 ./configure;制作;进行安装；作为3个单独的步骤？

【发布时间】：2012-06-13 06:09:07

【问题描述】：

每次从源代码编译某些东西时，都会经历相同的 3 个步骤：

$ ./configure
$ make
$ make install

我明白，将安装过程分成不同的步骤是有意义的，但我不明白，为什么这个星球上的每个编码人员都必须一遍又一遍地编写相同的三个命令，只是为了得到一个任务完成。从我的角度来看，将./install.sh 脚本与包含以下文本的源代码一起自动交付是完全有意义的：

#!/bin/sh
./configure
make
make install

为什么人们会分开执行这 3 个步骤？

【问题讨论】：

如果构建系统编写正确——通常是这样——你可以省略第二步。

你的问题并不愚蠢。您可以在 Linux 环境中构建您的程序，然后您可以使用某些虚拟化应用程序，也可以使用 mingw 在 Windows 环境中直接构建。

gnu.org/software/automake/manual/html_node/Why-Autotools.html

【参考方案1】：

因为每一步都做不同的事情

为构建准备（设置）环境

./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 相关设置或其他不同的东西。

如您所见，拆分每个状态使维护和部署变得更加容易，尤其是对于包维护者和发行版。

【讨论】：

大约一年后再次阅读这篇文章，我必须补充一点，这一切都说得通，而且仍然可能有一个命令调用使用默认配置完成所有 3 个步骤。它们都有一个默认配置，否则你不能简单地在没有参数的情况下调用它们。

有时我可以在没有 make 的情况下进行安装。这是什么意思？如果我跳过 make，我可以只进行 make install 吗？

install 依赖于all 因此make install 将调用make all

很好的答案，但是我不明白为什么有时需要安装，而有时不需要（一个制作，做所有的魔法）

make install 只需将各种资源安装到预定义的位置。如果您只关心可执行文件，则可以使用构建目录中的可执行文件并将构建目录添加到您的 PATH。

【参考方案2】：

首先，它应该是./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 设置为规则对于很多经常这样做的人来说会很不方便！

【讨论】：

感谢&&的建议！

【参考方案3】：

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 有他们的追随者。但构建过程的各个部分（如配置、构建和安装）仍然是单独的命令。

【参考方案4】：

首先，./configure 并不总能找到它需要的所有东西，或者在其他情况下，它会找到它需要的所有东西，但不是它可以使用的所有东西。在这种情况下，您会想知道它（并且您的 ./install.sh 脚本无论如何都会失败！）从我的角度来看，具有意外后果的非失败的经典示例是编译大型应用程序，如 ffmpeg 或 mplayer。如果它们可用，它们将使用库，但如果它们不可用，则无论如何都会编译，从而禁用某些选项。问题是你后来发现它是在不支持某种格式的情况下编译的，因此需要你回去重做。

./configure 以交互方式做的另一件事是让您可以选择自定义应用程序在系统上的安装位置。不同的发行版/环境有不同的约定，您可能希望遵守系统上的约定。此外，您可能希望在本地安装它（仅供您自己使用）。传统上 ./configure 和 make 步骤不以 root 身份运行，而 make install（除非它是为您自己安装的）必须以 root 身份运行。

特定发行版通常会提供脚本，这些脚本以对发行版敏感的方式执行此 ./install.sh 功能 - 例如，source RPMs + spec file + rpmbuild 或 slackbuilds。

（脚注：话虽如此，我同意 ./configure; make; make install; 会变得非常乏味。）

【讨论】：

一切都可以理解，但在我看来，如果您有一个包含三个步骤的附加文件，这些可能性都不会被破坏。例如。如果您想读取一些配置标准输出，您仍然可以对其进行 grep 或将整个标准输出放入文件中，然后再读取。

是的，但是，为什么需要文件？只需使用别名（尽管您必须想一个比“confmakeins”更好/更短的名称，但我今天没有灵感！）。别名 confmakeins='./configure && make && sudo make install'; cd 源目录； confmakeins;

听起来不错。我自己从来没有写过别名，所以我没有考虑过！