Workarounds mentioned in:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/LV5CEWSE6IFNRKVS64RWNGB7H4EJBX6H/

Hmm, I would've sworn I already did just that, but clearly not. Another memory cell malfunction, hmph. But yes, absolutely.

Created attachment 1382329 [details]
Patch to introduce %build_* macros

I'm attaching a patch to introduce various %build_* macros and some comments to document them.

I tested this by building bash, lua, ninja-build.

I'm keeping the old %__global_* names for now because some existing spec files use them.

%__global_compiler_flags is used in rpmrc too, that needs to be updated as per the new name if the old one is deprecated.

Other than that, I don't see anything obviously wrong. As with any naming related thing, there's endless potential for bikeshedding, such as:
- why not just %cflags, %ldflags etc
- ...or %CFLAGS, %LDFLAGS etc (but might actually be too easy to mixup with the shell variables)
...but I've no particular problem with the %build_foo naming either.

Let me mull over this a bit. I'm actually looking/planning to upstream the result of this into rpm itself eventually so if something I say here sounds out of context... but don't let me get hung over that.

On a related note, %__global_ldflags is getting also passed to the build environment as RPM_LD_FLAGS in Fedora (which is also been to-be-upstreamed-some-day-in-some-form since forever):
https://src.fedoraproject.org/rpms/rpm/c/4dd6dd15e611bac9d48893bdd9ed0cfb0e978818?branch=master

I deliberately did not touch %__global_compiler_flags in my patch.  I'll add a reference to RPM_LD_FLAGS to an updated patch.

Oops, sorry. Not looking carefully enough, obviously.

Actually the bigger reason for mentioning RPM_LD_FLAGS was that it points out another (alternative) way of exporting this data to the environment. We could just as well export the existing __global_* flags via RPM_FOO_FLAGS env variables, only in that case the patch goes to rpm and not redhat-rpm-config. Or do both...

I would like to concentrate most of the flag maintenance in redhat-rpm-config.  It may also be desirable to add a Lua-based macro which allows queries like “give me all warning flags” or “give me all code generation/ABI variant flags”.

Sure, and exporting (additionally) via environment variables doesn't actually change that. The flags are set in redhat-rpm-config macros, only the export part needs to go to rpm because we're not overriding %___build_pre. That's how the ldflags-thing is done atm.

Created attachment 1386529 [details]
Patch to introduce %build_* macros

Updated patch, now with documentation in buildflags.md.

I did not make any material changes, the way things are structured is essentially the same.  I do not think it is worth the effort to try to redistribute the flag setting responsibilities between rpm/%build and this package.

I'm coming down with a flu and not feeling particularly well or bright today, but lets try to get this thing moving... At least one concrete bug introduced in the patch:

+* `%{build_fclags} for `FFLAGS` (the Fortran compiler flags, also
+  known as the `FCFLAGS` variable).
[...]
+  FFLAGS="${FFLAGS:-%{build_fflags}}" ; export FFLAGS ; \
+  FCFLAGS="${FCFLAGS:-%{build_fcflags}}" ; export FCFLAGS ; \

These refer to %{build_fcflags} but that's not defined in the patch, only %{build_fflags} is.

+%__global_fflags %{build_fflags}
+%__global_fcflags %{build_fflags}

...and then the latter one should be %{build_fcflags}.

[...]
+# Note: __global_ldflags is used by RPM in %%___build_pre to set RPM_LD_FLAGS.

I'd leave that implementation detail out, we can just switch rpm to use the new value once its in redhat-rpm-config (and perhaps export the other values similarly in the environment while at it).

I've had couple of weeks to mull over it and nothing's come out of it so ... after fixing the fflags/fcflags confusion (and maybe the ldflags thing) just go ahead with.

Thanks, applied with these fixes.