对于那些从源代码编译的人来说，运行“./configure”只是为了发现 X 库或丢失是多么痛苦，最糟糕的是它会吐出一个愚蠢的行，说一个神秘的 lib 文件丢失了，然后，您必须转到网络浏览器中输入丢失的文件，让 Google 可以为您找到答案...
我觉得这很重复，所以我的问题是：
有没有办法解决所有必需的依赖项但不执行“./configure”
【问题讨论】：
阅读源代码分发中的 README* 或 INSTALL* 文件（如果有），或在您下载文件的网站上查找任何文档。如果包有很好的文档，依赖项通常会在某个地方列出。
【讨论】：
鉴于没有提及特定的 pkg，我认为这是一个通用的“如何避免使用配置”问题。从源代码压缩包中，没有自动化的方法来解决依赖关系。这就是 configure 的用途（您总是可以阅读 Makefiles 和 autoconf 文件并手动理解依赖关系，但是您很快就会错过 configure ）。为避免这种情况，您需要使用其他已经解决依赖关系的直接 tarball。
例如，您可以切换到构建源 rpm（或 deb，取决于您的系统）。或者你可以使用像 Gentoo 这样非常擅长为你解决依赖关系的系统。但是所有这些都需要您感兴趣的 pkg 以它们的格式提供，因此它们不适用于您从源提供程序下载的 tarball。
【讨论】：
阅读configure.ac/configure.in。查找对AC_CHECK_LIB、AC_CHECK_LIBS、AC_SEARCH_LIBS、AM_PATH_* 的调用（一些不使用pkg-config 的旧包出于某种原因将它们的检查放入AM_* 命名空间）、PKG_CHECK_MODULES（用于pkg-config)、AX_*（编写了许多 autoconf-archive 宏来检查不常见的依赖项）和任何以奇怪名称开头的宏调用（即，不是 AC_*、AM_* 或 AX_*。试试@ 987654335@?)。
【讨论】：
您可以做的对社区有益的一件事是向软件包维护者提交错误报告/功能请求。有很多包的配置脚本不会在第一个丢失的依赖项上中止，而是运行到完成，然后打印所有丢失的依赖项的摘要。这大大减少了您描述的乏味。不幸的是，“相当多”转化为不到 0.00001%（这是一个虚构的统计数据）。如果你能说服包维护者重新编写他们的配置脚本来支持这种行为，你将有助于让世界变得更美好。
祝你好运！
【讨论】：