From Fedora Project Wiki


The autotools (autoconf, automake, and libtool) are designed to be run by developers to create a portable shell script named configure that is included in the upstream tarball. The configure script will test what functionality is available on the system it is being built on and generate a Makefile that will build the software accordingly. In general, packages which uses the autotools should have their configure script run in the package's spec file (via the %configure macro) and should not run autoconf, automake, and libtool to regenerate that shell script.

Sometimes, however, a package will not build correctly without fixes to the the build scripts. When this occurs there are two valid strategies.

Running Autotools in the spec file

With this strategy, you patch the files that the autotools take as input (most commonly and and then rerun the autotools on them in the spec file like this:

Patch0: configure-fix.patch
BuildRequires: autoconf
BuildRequires: automake
BuildRequires: libtool    # If we're building libraries
%patch0 -p1 # Makes changes to what's in
autoreconf --force --install

Unless the fix you make is Fedora specific, you can usually submit these types of patches upstream.

Remember that if you do things this way you should validate that what you've created works. Running autoreconf may create a configure script using a different version of the autotools than what was used to generate the configure script in the tarball. Different versions of the autotools sometimes lead to subtle changes in behaviour that could compile the software with slightly different preprocessor definitions and compile the code in a way you (and upstream) weren't expecting.

Put more stress on autotools versioning incompatibilities

Patching the generated files

You can also directly change the files that the autotools produce (generally the configure script and the files). If you do this, [...]