READONLY is supported in ld.bfd from binutils >= 2.38, though the
patch was backported in rawhide. It is also unsupported by ld.gold,
so let's make it easy to skip it, since things will also work without
it, just a tiny bit worse.
Thanks to this the file is (in the common case) created in the unpacked
build directory, and not one level up. I.e.
/builddir/build/BUILD/lirc-0.10.0/.package_note-lirc-0.10.0-34.fc36.x86_64
instead of /builddir/build/BUILD/.package_note-lirc-0.10.0-34.fc36.x86_64.ld.
This is nicer esp. for 'fedpkg local' builds, where the dist-git directory is
used as the build dir.
When there are multiple %setup calls, the *last* extracted directory
becomes %{buildsubdir}. This might be confusing, but it shouldn't cause
problems for this use.
Suggested in https://bugzilla.redhat.com/show_bug.cgi?id=2043092#c21.
IIUC, the normal %ifarch syntax cannot be used, because the definition
needs to be inline. The best I could find is %_target_cpu, which seems to be
set to "noarch" for noarch builds.
When subpackages are used, and have different Version fields, we end up with
the version of the last subpackage in %version. But RPM_PACKAGE_VERSION is
set early, and seems to have the right version.
Fixes rhbz#2043143.
The idea was that we can avoid unnecessary work if the macro is called more than
once. But in hindsight this might be risky: let's instead minimize the number of
places where the macros is called, but always overwrite the file so that we
don't end up with a stale version from a previous build.