We should definitely do that and have a section about Autotools in our docs like we do for Meson and CMake.

I've always enforced this when reviewing packages. Few do it, max 5 cases over thousands of packages.

+1 to ban it

FPC was receptive to a ban, so I will work on a PR.

I do like the idea of having an Autotools section but to be honest I don't know what would actually be said in it. Autotools isn't exactly simple and there is more magic crammed into the %configure macro than ever before. Does that need to be discussed or is it sufficient to just say: "call %configure, %make_build and %make_install in the right places (never %prep); here's a template"?

That sounds good to me. The more specific the guidance, the likelier it is wrong in more cases, where autotools are concerned ... (since their usage is extremely heterogeneous ...)

Similarily, I've seen packages run autoreconf in %prep. Should that be discouraged? (It fails when you fedpkg prep without autoconf.

Sure .. I don't think people should run any build tools in %prep, but just basic shuffling things around so the sources, files, and directory layout is prepared (i.e. running programs like tar, cp, mv, unzip is expected, but running autoreconf is not).

IMO configure was out because that can call gcc to do tests ... autoreconf ... eh. I think it should be in build but I'm not as strongly for it.

+1 for banning %configure in %prep.

As for autoreconf, I always run it in %prep since typically it's required because of patches for autotools. It just generates configure - which otherwise you wouldn't need to touch - and it therefore makes sense to have it in %prep. It's not configuring the build, it's preparing the source tree.

I think running %configure in %prep is closely analogous to running %cmake or %meson; all of these are build system generators that accept configuration options and emit files consumed by the “real” build system (make or ninja). I don’t think anyone would argue for running %cmake or %meson in %prep.

As far as autoreconf is concerned, I have an aesthetic preference for only doing unpacking and patching in %prep, but I also don’t like doing other things there for the practical reason @churchyard mentioned: it increases the number of packages that have to be manually installed on a developer’s system to run fedpkg prep or fedpkg srpm. For autoreconf, this is at least autoconf/automake/libtool, but it can even include some -devel BR’s that provide their own m4 macros in aclocal, e.g. libgpg-error-devel.

For some context, we used to have some useful tooling which would try to run spectool -g and run the %prep phase of everything (in a relatively basic system without trying to install build dependencies). This might even have been pre-fedpkg. So from my perspective, there is utility in keeping the dependency set needed to run %prep as small as possible but I never really got around to proposing any guidelines to that effect. (And I'm not sure it's particularly useful to just say "try to keep %prep simple.")

Yes, %configure and the like do not belong in %prep.

On a related note: rpm >= 4.18 will have a new spec section %conf specifically for configuring the build. Of course it'll be a while before it can be used throughout Fedora, never mind EL variants, but just FYI.

On a related note: rpm >= 4.18 will have a new spec section %conf specifically for configuring the build

What is the usecase? Do you want to change Fedora policy to start using this feature?

As above ./configure is kind of weird in that it'll often end up compiling and running arbitrary programs, so separating it from build seems kind of weird unless you want to save the result of configure in some way.

%conf is primarily preliminaries for a future feature, and it'd be premature to start pushing Fedora policies around it now. Just wanted to mention it in now to raise awareness and to avoid perhaps decisions that would make its adoption more difficult later.

Configuration is a separate step from the build though, so even now it's beneficial for the same reasons that configure/make are separate, when working on a spec. Of course for --rebuild kind of use there's no difference.

Yeah we'll probably want to mention it when F37 progresses a bit. Someone will certainly be asking if it can be used but we certainly wouldn't want to change any examples and such until closer to the time F36 goes EOL (if at all).

But I imagine we will want to work on using that build templating feature soon after it's available,

Hm ... looks like this ticket was closed as "accepted" but no actual changes to the packaging guidelines were made? Or can I just not find the changes?

You are probably right; I did do some work on this a couple of years ago but I got bogged down trying to actually write guidelines for autotools as a build system just like cmake and meson have guidelines. Which I think is what should be done eventually, but that gets into the question of when to run autoreconf and that is a whole other can of worms that needs its own discussion. And then there's the question of whether to talk about %conf (which is universally available in Fedora at this point, but obviously not across EPEL versions).

Another tool worth mentioning is QMake (usually invoked as e.g. %{qmake_qt6}). I’m inclined to say that it also belongs in %conf since it accepts configuration-type arguments and generates Makefiles, similar to Automake.