--Dmalcolm 00:27, 12 March 2010 (UTC): I believe this draft, as written, is controversial. For what it's worth, I strongly disagree with the proposed policy, see also http://lists.fedoraproject.org/pipermail/devel/2009-February/023647.html
Using autoconf/automake in spec files
This document seeks to document the usage of autoconf
, automake
, and libtoolize
during a package build in Fedora; i.e. the usage of older packages like autoconf213
and automake1{4,5,6,7}
.
Problem
- Autoconf, Automake, and Libtool (collectively, the “autotools”) can by used for many Fedora packages to create
configure
scripts andMakefile
s. The resultingconfigure
scripts andMakefile
s might be different on systems with a different set of installed packages and thus might lead to unpredictable results. In particular, when any of Fedora's autotools packages is upgraded, the new version may not be compatible with the autotools input files in Fedora's numerous autotools-derived upstream source packages.
- Some packages use old autotools versions in order to build their
configure
scripts andMakefile
s. Some of these older helper tools aren't multilib capable and patches need to be applied to be able to build the package on multilib systems. Upstream doesn't maintain these tools anymore and so the tools won't get any bugfixes.
Solution
- Autotools-generated source packages are intended to be buildable without requiring the autotools on the host system.
autoconf
,automake
,libtoolize
and the accompanyingautoreconf
shouldn't be used in the%prep
or%build
sections of a package's spec file. Applying a patch to update theconfigure
scripts andMakefile.in
s is preferred as the results are predictable and packages are more reproducible.
- When manual modification of
configure
orMakefile.in
for the purpose of generating a patch is impractical, packagers can create a patch by regeneratingconfigure
and/orMakefile.in
to use as input todiff
. In general,autoreconf
should not be used for this purpose because it will regenerate files that probably don't need to be regenerated.- If only
Makefile.am
has been touched, runautomake
to regenerateMakefile.in
. - If
configure.ac
(or in older packages,configure.in
) has been modified, but no additional Autoconf macros were invoked, runautoconf
to regenerateconfigure
. - If new macro invocations have been added to
configure.ac
, first runaclocal
(to regenerateaclocal.m4
), then runautoconf
. Many projects distribute their own Autoconf macros in an “m4
” or “macros
” subdirectory; you will need to provideaclocal
with a-I
flag with the path to these macros. Note that you do not need to include modifications toaclocal.m4
in your patch.
- If only
- Package maintainers should work with upstream to port the scripts to recent autotools. Sometimes this won't work due to time constraints or due to compatibility concerns for multi-platform packages such as p.e. Firefox; but at least an attempt should be made.
Further reading
Updating from autoconf213
to a recent version is covered at Upgrading From Version 2.13.
Tips to update from older Automake versions are available at Upgrading a Package to a Newer Automake Version (dead link). The NEWS
file in the latest automake
package also lists differences between the versions and gives some hint what one has to look out for.