我多久运行一次 autoconf？
在我的公司中，我目前正在致力于从第 3 方库创建 Debian deb 软件包。 该库是使用 Autotools 构建的。 我以前从未使用过 Autotools，因此遇到了一些困难。 库源包含 configure.in 和 Makefile.am 文件以及 m4/ 目录。 我可以使用以下顺序构建库：
aclocal -I m4 -I /usr/share/aclocal
autoheader
libtoolize --automake
automake -a
autoconf
./configure
make
在 debian/rules 文件中，我想使用 CDBS。 我这样写：
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk
但这不起作用。 它抱怨 configure 文件丢失。 没错，因为 Autotools 类期望此文件存在。 但它不存在，必须有人先调用 autoconf 和朋友！
为什么 Autotools CDBS 类不允许我调用 autoconf 和朋友？ 我该如何规避它？
题外话：
当我使用一个程序时，我不会每次都编译它，我会编译一次并重用二进制文件。
当人们安装软件时，他们不会自己编译它，维护者会编译一次，人们会重复使用二进制包。
当维护者编译包时，他/她不会每次编译时都创建 configure 脚本，上游作者创建一次，维护者可以重用它。
最后一句话是真的吗？ 因为对我来说，Autotools CDBS 类的作者似乎假设了这样的事情 - 他们假设配置存在，并在为不同架构编译包时重用它。 我对吗？
一方面，如果可以生成 configure ，它就不应该出现在任何地方 - 如果您需要它，您可以从其他文件生成。 另一方面，Autotools CDBS 类的作者一定有某种原因以这种方式实现它，而不是其他方式。
摘要：
- 如何处理上述 Autotools CDBS 类问题？
- 我多久重新生成一次
configure？ （一般情况下以及构建 Debian 软件包时。）
In my company I'm currently working on creating a Debian deb package out of a 3rd party library. The library is built using Autotools. I have never worked with Autotools before and I'm having some hard time. Library sources contain configure.in and Makefile.am files and m4/ directory. I am able to build the library using this sequence:
aclocal -I m4 -I /usr/share/aclocal
autoheader
libtoolize --automake
automake -a
autoconf
./configure
make
In debian/rules file I'd like to use CDBS. I wrote this:
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk
But it doesn't work. It complains that the configure file is missing. And that's right, because the Autotools class expects this file to be present. But it's not there and someone has to call autoconf and friends first!
Why Autotools CDBS class doesn't let me call autoconf and friends? How do I circumvent it?
A digression:
When I use a program, I don't compile it every time, I compile it once and reuse the binary.
When people install software, they don't compile it by themselves, maintainer compiles it once and people reuse the binary package.
When maintainer compiles the package, he/she doesn't create configure script every time he compiles, the upstream author created it once and the maintainer can reuse it.
Is that last sentence true? Because to me it seems like authors of the Autotools CDBS class assumed such thing - they assume configure to be present, and reuse it while compiling package for different architecture. Am I right?
On one hand, if configure can be generated, it shouldn't be present anywhere - if you need it, you generated from other files. On the other hand, authors of the Autotools CDBS class must have had some reasons for implementing it this way and not the other.
Summary:
- How do I deal with the Autotools CDBS class problem described above?
- How often do I regenerate
configure? (In general and when building Debian packages.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，你工作太辛苦了。 而不是运行 aclocal && 自动标题&& ETC...，
你可以运行 autoreconf 。 这将确保以正确的顺序调用所有自动工具（并且对手指和大脑来说更容易）。 其次，生成配置脚本后，您应该创建一个构建目录并运行“make dist”以获取将用于生成 deb 的 tarball。 tarball 中将包含配置脚本。 （更好的是，只需使用上游生成的 tarball，根本不用担心运行自动工具。）
First, you're working too hard. Rather than running aclocal && autoheader && etc...,
you can just run autoreconf. This will ensure that all the autotools are invoked in the correct order (and is easier on the fingers and the brain). Second, once you've generated the configure script, you should make a build directory and run 'make dist' to get a tarball that will be used to generate the deb. The tarball will have the configure script in it. (Better yet, just use the tarball generated by upstream and don't worry about running the autotools at all.)
Jasiu，
配置脚本确实是由上游作者创建的，通常不需要由其他人重新生成。 但有时，当原始配置出现问题时，可能需要运行自动工具（使用较新版本的自动工具或更新的 m4 宏）。
通常，仅当您对configure.ac、Makefile.am、m4宏等进行更改时才运行autotools。
顺便说一句，如果autoconf足够新，您只需调用autoreconf即可生成configure。 但如果原来的配置没有问题，就保持原样即可。
Jasiu,
that's true that configure script is created by upstream author and usually doesn't need to be regenerated by anyone else. But sometimes, when there is a problem with the original configure, one may want to run autotools (with newer versions of autotools or with updated m4 macros).
Usually you run autotools only when you make changes to configure.ac, Makefile.am, m4 macros, etc.
BTW if autoconf is new enough you can just call autoreconf to generate configure. But if there are no problems with the original configure, just leave it as it is.
为了回答最初的问题“为什么 Autotools CDBS 类不允许我调用 autoconf 和朋友？我该如何规避它？”，我所做的是将以下规则添加到 debian/rules 文件中：
此规则基本上运行 autoreconf --install 命令（如果存在 configure.ac 和 Makefile.am 文件，它将为您生成配置脚本）作为包的预配置操作。 目标规则记录在此处： http://cdbs-doc.duckcorp .org/en/cdbs-doc.xhtml#id489203
就像adl所说，开发人员应该能够运行autoreconf来为其开发重新生成配置脚本，因此只应检查configure.ac和Makefile.am文件进入SVN。 但是，当源代码发布给最终用户时，应提供配置脚本，以便最终用户可以运行配置脚本，而无需工具来生成它。
To answer the original question of "Why Autotools CDBS class doesn't let me call autoconf and friends? How do I circumvent it?", what I did was add the following rule to the debian/rules file:
This rule basically runs the autoreconf --install command (which will generate the configure script for you if configure.ac and Makefile.am files are present) as your package's pre-configure action. The target rule is documented here: http://cdbs-doc.duckcorp.org/en/cdbs-doc.xhtml#id489203
Like adl said, developers should be able to run autoreconf to regenerate the configure script for their development, and hence only configure.ac and Makefile.am files should be checked into SVN. However, when the source is released to end-users, the configure script should be provided so end-users can run the configure script without needing the tools to generate it.
您通常应该从版本构建 debian 软件包，这样您就知道您正在打包什么 - 通常是 tarball 软件包-VERSION.tar.gz。 在这种情况下，通常不需要运行自动工具，除非 config.{sub,guess} 太旧并且无法在目标系统上运行。
不管怎样，你问了很多问题，但第一个是基于问题的：
这并不能解释失败的原因。问题顶部的序列包括运行
./configure，因此它不会丢失。configure 始终存在，因此您后面的大多数问题都相当令人困惑。You should typically be building debian packages from releases so you know what you are packaging - that's usually tarball package-VERSION.tar.gz. In that case, there is not usually any need to run autotools, except for the case where the config.{sub,guess} are too old and can't run on the targeted system.
Anyway, you asked a lot of questions but the first one is based on the problem:
which doesn't explain what failed. Your sequence at the top of the question includes running
./configureso it can't be missing.configureis always present when autotools are correctly run so most of your later questions are rather confusing.