Autotools
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 configure.ac and 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, [...]