From Fedora Project Wiki
No edit summary
No edit summary
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, and libtoolize 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 <code>autoconf</code>, <code>automake</code>, and <code>libtoolize</code> during a package build in Fedora; i.e. the usage of older packages like <code>autoconf213</code> and <code>automake1{4,5,6,7}</code>.


== Problem ==
== Problem ==


* Autoconf, Automake, and Libtool (collectively, the &ldquo;autotools&rdquo;) 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. In particular, when any of Fedora's autotools packages are upgraded, the new versions may not be compatible with the autotools input files in Fedora's numerous autotools-derived upstream source packages.
* Autoconf, Automake, and Libtool (collectively, the &ldquo;autotools&rdquo;) can by used for many Fedora packages to create <code>configure</code> scripts and <code>Makefile</code>s. The resulting <code>configure</code> scripts and <code>Makefile</code>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 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 <code>configure</code> scripts and <code>Makefile</code>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 ==
== Solution ==


* autotools-generated source packages are intended to be buildable without requiring the autotools on the host system. 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.
* Autotools-generated source packages are intended to be buildable without requiring the autotools on the host system. <code>autoconf</code>, <code>automake</code>, <code>libtoolize</code> and the accompanying <code>autoreconf</code> shouldn't be used in the <code>%prep</code> or <code>%build</code> sections of a package's spec file. Applying a patch to update the <code>configure</code> scripts and <code>Makefile.in</code>s is preferred as the results are predictable and packages are more reproducible.


* When manual modification of configure or Makefile.in for the purpose of generating a patch is impractical, packagers can create a patch by regenerating configure and/or Makefile.in to use as input to diff. In general, autoreconf should not be used for this purpose because it will regenerate files that probably don't need to be regenerated.
* When manual modification of <code>configure</code> or <code>Makefile.in</code> for the purpose of generating a patch is impractical, packagers can create a patch by regenerating <code>configure</code> and/or <code>Makefile.in</code> to use as input to <code>diff</code>. In general, <code>autoreconf</code> 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, run automake to regenerate Makefile.in.
** If only <code>Makefile.am</code> has been touched, run <code>automake</code> to regenerate <code>Makefile.in</code>.
** If configure.ac (or in older packages, configure.in) has been modified, ''but no additional autoconf macros were invoked,'' run autoconf to regenerate configure.
** If <code>configure.ac</code> (or in older packages, <code>configure.in</code>) has been modified, ''but no additional Autoconf macros were invoked,'' run <code>autoconf</code> to regenerate <code>configure</code>.
** If new macro invocations have been added to configure.ac, first run aclocal (to regenerate aclocal.m4), then run autoconf. Many projects distribute their own autoconf macros in an "m4" or "macros" subdirectory; you will need to provide aclocal with a <code>-I</code> flag with the path to these macros. Note that you do not need to include modifications to aclocal.m4 in your patch.
** If new macro invocations have been added to <code>configure.ac</code>, first run <code>aclocal</code> (to regenerate <code>aclocal.m4</code>), then run <code>autoconf</code>. Many projects distribute their own Autoconf macros in an &ldquo;<code>m4</code>&rdquo; or &ldquo;<code>macros</code>&rdquo; subdirectory; you will need to provide <code>aclocal</code> with a <code>-I</code> flag with the path to these macros. Note that you do not need to include modifications to <code>aclocal.m4</code> in your patch.


* 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.
* 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.
Line 25: Line 22:
== Further reading ==
== 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
Updating from <code>autoconf213</code> to a recent version is covered at [http://www.gnu.org/software/autoconf/manual/html_node/Autoconf-2_002e13.html#Autoconf-2_002e13 Upgrading From Version 2.13].


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.
Tips to update from older Automake versions are available at [http://sources.redhat.com/automake/automake.html#Upgrading Upgrading a Package to a Newer Automake Version]. The <code>NEWS</code> file in the latest <code>automake</code> package also lists differences between the versions and gives some hint what one has to look out for.

Revision as of 05:45, 12 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. 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 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

  • Autotools-generated source packages are intended to be buildable without requiring the autotools on the host system. 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.ins is preferred as the results are predictable and packages are more reproducible.
  • When manual modification of configure or Makefile.in for the purpose of generating a patch is impractical, packagers can create a patch by regenerating configure and/or Makefile.in to use as input to diff. 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, run automake to regenerate Makefile.in.
    • If configure.ac (or in older packages, configure.in) has been modified, but no additional Autoconf macros were invoked, run autoconf to regenerate configure.
    • If new macro invocations have been added to configure.ac, first run aclocal (to regenerate aclocal.m4), then run autoconf. Many projects distribute their own Autoconf macros in an “m4” or “macros” subdirectory; you will need to provide aclocal with a -I flag with the path to these macros. Note that you do not need to include modifications to aclocal.m4 in your patch.
  • 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. 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.