很多人在ref="/tag/150/" style="color:#479099;font-weight:bold;">编译软件时，看到教程里先运行 ./configure，接着 make，最后 make install，就以为 configure 命令是编译的一部分。其实，configure 并不负责编译，它干的是另一件更重要的事——配置。
configure 到底在做什么？
当你从源码安装一个开源项目时，比如 Nginx 或 FFmpeg，系统环境千差万别：有的有 GCC，有的用 Clang；有的库装在 /usr/local，有的在 /opt；32 位和 64 位系统也不同。这时候，直接编译很容易出错。
configure 就是来“探路”的。它是一个 shell 脚本，通常由 autoconf 工具生成，运行时会自动检测当前系统的编译器、库文件、头文件、系统架构等信息，然后根据这些结果生成适合你机器的 Makefile 文件。
你可以把它想象成装修前的量房。师傅还没开始砌墙（编译），但得先知道房间多大、水电怎么走，才能出施工图（Makefile）。
为什么不能跳过 configure 直接 make？
因为大多数源码项目不会自带通用的 Makefile。它们提供的是 Makefile.in 模板，里面有很多占位符，比如 @CC@ 表示编译器，@CFLAGS@ 表示编译参数。configure 运行后，把这些变量替换成实际值，才生成真正的 Makefile。
如果跳过这步，make 找不到正确的规则，大概率会报错“missing separator”或者“cc not found”。
常见用法示例
进入源码目录后，典型的流程是：
./configure --prefix=/usr/local/myapp
make
sudo make install其中 --prefix 是最常见的选项，用来指定软件安装路径。如果不加，默认可能装到 /usr/local 下，容易跟系统包管理器冲突。
你还可以通过 --disable-shared 启用静态编译，或者 --with-openssl=/path 指定第三方库位置。这些选项都会被 configure 记录下来，影响后续的编译行为。
configure 不是万能的
有时候运行 ./configure 会失败，提示“C compiler cannot create executables”。这通常不是 configure 本身的问题，而是环境缺了基础组件，比如没装 build-essential（Ubuntu）或 Xcode Command Line Tools（macOS）。
另外，configure 只检查它知道要检查的东西。如果你漏装了某个可选依赖，它可能默认关闭相关功能，编译能过，但软件运行时少特性，这种“静默降级”反而更难排查。
现代项目的替代方案
现在越来越多项目转向 CMake、Meson 等更现代化的构建系统。比如 CMake 用 cmake . 替代 ./configure，原理类似，但语法更清晰，跨平台支持更好。
不过，在 Linux 传统开源世界里，autotools（autoconf + automake）仍是主流，configure 命令还会继续存在很久。