From Fedora Project Wiki
m (1 revision(s))
(Updated to refer to libtoolize as well)
Line 1: Line 1:
= Using autoconf / automake in spec files =
= Using autoconf / automake in spec files =


This document seeks to document the usage of autoconf / automake during a package build in Fedora, i.e. the usage of older packages like autoconf213 and automake1{4,5,6,7}
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}




Line 8: Line 8:
== Problem ==
== Problem ==


* autoconf / automake can by used for many Fedora packages to create configure scripts and Makefiles. The resulting configure scripts and Makefiles might be different on systems with a different set of installed packages and thus might lead to unpredictable results.
* Autoconf, Automake, and Libtool (collectively, the “autotools”) can by used for many Fedora packages to create configure scripts and Makefiles. The resulting configure scripts and Makefiles might be different on systems with a different set of installed packages and thus might lead to unpredictable results.


* some packages use old autoconf / automake versions in order to build their configure scripts and Makefiles. 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.
* Some packages use old autotools versions in order to build their configure scripts and Makefiles. 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 ==
== Solution ==


* autoconf / automake and the accompanying autoreconf shouldn't be used in the %prep or %build sections of a packages spec file. Applying a patch to update the
* autoconf, automake, libtoolize and the accompanying autoreconf shouldn't be used in the %prep or %build sections of a package's spec file. Applying a patch to update the configure scripts and Makefile.in's is preferred as the results are predictable and packages are more reproducible.
configure scripts and Makefiles is preferred as the results are predictable and packages are more reproducable.


* Package maintainers should work with upstream to port the scripts to recent autoconf /automake. 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.
* 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 ==
== Further reading ==

Revision as of 19:10, 11 October 2008

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 and Makefiles. The resulting configure scripts and Makefiles might be different on systems with a different set of installed packages and thus might lead to unpredictable results.
  • Some packages use old autotools versions in order to build their configure scripts and Makefiles. 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

  • autoconf, automake, libtoolize and the accompanying autoreconf shouldn't be used in the %prep or %build sections of a package's spec file. Applying a patch to update the configure scripts and Makefile.in's is preferred as the results are predictable and packages are more reproducible.
  • 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 http://www.gnu.org/software/autoconf/manual/html_node/Autoconf-2_002e13.html#Autoconf-2_002e13

Tips to update from older automake versions are available at http://sources.redhat.com/automake/automake.html#Upgrading . 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.