The autotools (
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
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
Makefile.am) 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 configure.ac autoreconf --force --install %configure
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.
Patching the generated files
You can also directly change the files that the autotools produce (generally the
configure script and the
Makefile.in files). If you do this, [...]