For a real-world examle of the 2-3 benefit, a typical bcond case from Fedora
rpm.spec:
Existing spec:
```
%bcond_without libarchive
[...]
%if %{with libarchive}
BuildRequires: libarchive-devel
%endif
[...]
%prep
cmake \
[...]
%{!?with_libarchive:-DWITH_ARCHIVE=OFF}\
```
Using a section override for %conf would be effectively unchanged from existing.
Spec tags:
```
%bcond_without libarchive
[...]
%if %{with libarchive}
BuildRequires: libarchive-devel
AutobuildOption(conf): -DWITH_ARCHIVE=OFF
%endif
```
3 would work equally well, just look a little out of place in middle of those
spec tags. In some other situation it may be surrounded by other macros and a
tag would look out of place, but that's probably an uncommon situation,
actually. The above also *screams* to be it `BuildOption(conf)` instead of this
auto-silliness.
Yet another observation is that configuration is the only place where one
typically expects "dozens" of options. For actual build/install stages, it's
usually more a matter of adding a flag / argument or two to override some
specific thing. Or, that's what I thought. Looking at the Fedora spec
collection, there's all manner of stuff being passed to both %make_build and
%make_install (and never mind everything that falls outside these). So while I
initially thought perhaps only configuration deserves the 2-3 style arrangement
and others could do with just a simple _opts macro (ie 4), perhaps not so.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2620#issuecomment-1794339518
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/2620/c1794339...@github.com>_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
