While the autoreconf command is “external,” it does implicitly execute
m4 scripts, often including some that are included in the package source
distribution, in order to generate the configure script. Note also that
autogen.sh is rarely more than a trivial one-to-five-line wrapper around
Sometimes autoreconf also needs m4 scripts that are installed with the
-devel packages of various dependencies. For example, gtk2-devel
provides /usr/share/aclocal/gtk-2.0.m4, which provides the
AM_PATH_GTK_2_0 macro, which can be used in dependent packages’
configure.ac files to generate GTK2 detection code. Such packages would
need gtk2-devel installed in order to run autoreconf. Sometimes copies
of these m4 files are provided with the dependent package sources, and
sometimes they aren’t.
This is why I don’t personally like autoreconf happening in %prep: it
can add arbitrary dependencies (not just autoconf/automake/libtool), and
I think it is valuable to be able to run “fedpkg prep” or similar
without installing extra dependencies on the packager’s system.
On 4/12/22 10:04, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Apr 08, 2022 at 11:16:59AM +0200, Petr Pisar wrote:
>> V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
>>> == Summary ==
>>> Update RPM to the [https://rpm.org/wiki/Releases/4.18.0
>>> * New `%conf` spec section for build configuration
>> RPM documenation reads:
>> In %conf, the unpacked sources are configured for building.
>> Different build- and language ecosystems come with their own helper macros,
>> but rpm has helpers for autotools based builds such as itself which
>> typically look like this:
>> In context of autotools, sources usually bundle a configure script. To follow
>> the open source way (and ensure portability to new platform and include
>> autotools fixes), building from the real sources is desired. Hence I do my
>> best to call "autoreconf -fi" before %configure.
>> Where should autoreconf be placed? %pre or %conf?
> For me the important distinction is that %prep should *not* execute the
> code from the package: it should just unpack, apply patches and fixups, change
> permissions, etc. This all should be done using external tools, and not
> scripts from the package itself. This way it is possible do 'fedpkg prep'
> or equivalent and view the sources without executing any commands from
> the package. So even if the package does not want to run on a given architecture,
> or upstream does something stupid or hostile, %prep remains reliable.
> (This also means that %prep should rather do less than more.)
> If autoreconf is done using the external 'autoreconf' command, then
> %prep seems appropriate. Some packages have ./autogen.sh or similar, and
> that I'd put in one of the later sections.
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure