[Rpm-maint] [rpm-software-management/rpm] Implement a declarative autobuild system (prototype) (PR #2620)

Panu Matilainen notifications at github.com
Mon Nov 6 08:52:44 UTC 2023


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/c1794339518 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20231106/163b0a45/attachment.html>


More information about the Rpm-maint mailing list