4

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.)
dajobe
  • 4,938
  • 35
  • 41
Jasiu
  • 2,674
  • 2
  • 27
  • 27

4 Answers4

6

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.)

William Pursell
  • 204,365
  • 48
  • 270
  • 300
1

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.

marcin
  • 3,351
  • 1
  • 29
  • 33
  • 1
    But if `configure` can be generated from `configure.ac` and `Makefile.am`, shouldn't we always distribute the latter two? Distributing `configure` to me is like putting binary files into a repository. – Jasiu Jun 29 '09 at 20:07
  • 4
    The GNU Build System requires `./configure && make && make install` to work right after you have extracted the tarball, so `configure' script should be distributed in the tarball. It's not the only kind of generated files that we like to distribute: Makefile.in, Bison-generated parsers, Texinfo documentation are all generated from other file, and distributed so that end-users do not need to install the tools to regenerate them. What goes in a repository is different from what goes in a user tarball. Developers often omit generated files, but then it's their job to run regenerate them all. – adl Jul 01 '09 at 12:37
0

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:

makebuilddir/your_package_name::
autoreconf --install

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.

-1

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:

"But it doesn't work. It complains that the configure file is missing."

which doesn't explain what failed. Your sequence at the top of the question includes running ./configure so it can't be missing.

configure is always present when autotools are correctly run so most of your later questions are rather confusing.

dajobe
  • 4,938
  • 35
  • 41
  • CDBS expects `configure` script to be already present. The sources we got contained only `configure.ac` and `Makefile.am`. I put those two into our SVN repo, but I didn't want to put `configure` in there, because it can be generated from the two other scripts. Because of them I can't perform automated package build, because CDBS looks for `configure` and it's not there. Why do people distribute sources with `configure` script? Shouldn't they distribute `configure.ac` and `Makefile.am` instead? – Jasiu Jun 29 '09 at 20:10
  • @Jasiu: No they shouldn't. configure should be distributed so that end-users don't need Autoconf/Automake and all their dependencies on their host. (Some package also use very specific version of the autotools, it would be foolish to request everybody to downgrade or upgrade autotools in order to install a package.) – adl Jul 01 '09 at 12:26
  • if you are using external release as a 'vendor', then you should include all files that the vendor tarball originally contained in your subvesion. If you are using a source code approach, then you will need to run the autotools although as I said above, you do not mention the exact error message that is the failure such that it could be diagnosed why there is no configure. autotools can fail in many ways - provide a log. – dajobe Jul 03 '09 at 00:44