典型的 ./configure 在 Linux 中起什么作用?
即使所有内容都在 makefile 中指定,为什么还是有必要?
Why is it necessary even though everything is specified in a makefile?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
即使所有内容都在 makefile 中指定,为什么还是有必要?
Why is it necessary even though everything is specified in a makefile?
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
接受
或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论(3)
通常,配置脚本运行时将:
检查有关计算机的一些详细信息
该软件将在其上
安装。该脚本检查
对你的系统有很多依赖。
为了使特定软件工作
正确地说,可能需要很多
存在于你的事物中的
机器已经。如果您的系统缺少任何主要要求,配置脚本将
退出
并且您无法继续安装,直到您获得这些必需的东西。创建要在下一步中使用的
Makefile
。Typically the configure script when run will:
Check some details about the machine
on which the software is going to be
installed. This script checks for
lots of dependencies on your system.
For the particular software to work
properly, it may be requiring a lot
of things to be existing on your
machine already. If any of the major requirements are missing on your system, the configure script would
exit
and you cannot proceed with the installation, until you get those required things.Create the
Makefile
to be used in the next step.它运行一个通常生成 makefile 和“configure.h”的脚本。
该脚本是用宏语言“m4”编写的。顶级宏可在 autoconf.ac 或(在旧系统中)autoconf.in 中找到。这些扩展包含较低级别的宏,这些宏又扩展为实际测试,创建小程序或任务来检查您拥有哪种系统。
例如,AC_CHECK_HEADER([myheader.h], ...) 可能会生成一个微小的 C 程序,如下所示:
如果程序编译,则检查被视为“通过”,否则“失败”。此类检查的状态通常会反映在 config.h 文件中。在通过检查时,您可能会在 config.h 中发现一行,如下所示:
while on a test that failed, it might look like
When配置为在 AM_INIT_AUTOMAKE 宏中使用 autoconf,Makefile 还可以引用测试的结果,如果导出包含测试结果的变量。因此,如果所需的库位于几个不同的典型位置,或者与您的标准工具之一(如 tar、ar 等)“有效”的语法不同,或者首选工具不可用,则 Makefile 将是仍然能够使用不同的库位置、不同的工具语法或不同的工具集正确构建项目。
因此,在处理 Autotools 项目(configure / make / make install)时,Makefile 实际上并不包含构建项目所需的所有内容,它是从 Makefile.in 模板生成的,以便在您键入“configure”时专门匹配您的系统。
It runs a script which typically produces makefiles and "configure.h".
The script is written in the lanugage "m4" which is a macro language. The top level macros are found in autoconf.ac or (in older systems) autoconf.in. These expand containing lower level macros which in turn expand into actual tests which create small programs or tasks to check what kind of system you have.
For example AC_CHECK_HEADER([myheader.h], ...) might generate a tiny C program like:
If the program compiles, the check is considered "passing" otherwise it "fails". The status of such checks often gets reflected in the config.h file. On a passing check, you might find a line in config.h that looks like:
while on a test that fails, it might look like
When configured to work with autoconf in AM_INIT_AUTOMAKE macro, the Makefile can also reference the results of the tests if the variable containing the test result is exported. So if a needed library is located a few different typical locations, or the syntax of "what works" with one of your standard tools (like tar, ar, etc) is different, or the preferred tool is not available, the Makefile will be able to still build the project properly using the different library locations, the different tool syntax, or a different set of tools.
So when dealing with an Autotools project (configure / make / make install) the Makefile really doesn't contain everything necessary to build the project, it's generated from the Makefile.in template to specifically match your system when you type "configure".
配置脚本从模板构建 Makefile,替换诸如要安装代码的位置以及用于构建程序的(C、C++、Fortran 等)编译器所需的定义等内容。从理论上讲,这一切都可以一步完成,只不过可能有许多不同的配置,分阶段完成会更容易。 (例如,如果使用可用的多核机器构建大型程序,您可能需要指定发生一定数量的并行编译,这与如何配置无关。)
A configure script builds the Makefile from a template, substituting in things like where you want to install the code and what definitions are needed for the (C, C++, Fortran, ...) compiler that is used to build the program. Theoretically it could all be done in one step, except that there's that many different configurations possible that it's easier to do in stages. (For example, if building a large program with a multi-core machine available, you might want to specify that a certain number of parallel compilations happen, which is not the concern of how things are configured.)