* Tom Stellard:
>> * It will make it easier to determine which packages disable
or add
>> compiler flags by doing a simple grep of the spec files.
>> * It will make it easier for toolchain developers to experiment with
>> adding new flags to the distribution as this can be done with a simple
>> macro definition instead of patching redhat-rpm-config.
> The main problem are these two goals. I don't think you can have it
> both ways.
> Here's a concrete example. The proposal mentions compiler-rt.spec
> as a
> potential use case. Say it changes
> %global optflags %(echo %{optflags} -D_DEFAULT_SOURCE)
> to:
> %global _pkg_extra_cflags -D_DEFAULT_SOURCE
> While this is arguably useful (second use case), after this change,
> it
> is no longer possible to inject additional build flags via
> _pkg_extra_cflags from the outside (third use case).
> Do we actually need two sets of macros, with distinct use cases?
>
This is a good point. So, it seems like adding something like
%_distro_extra_cflags in addition to %_pkg_extra_cflags might make
sense. However, as I've been working on this, it seems to me that
the ability to inject distro-wide build flags (%_distro_extra_flags)
is much more useful that having a convenience macro for packages to
add their own flags (%_pkg_extra_cflags). So, just renaming %_pkg_extra_flags
to %_distro_extra_cflags would be OK with me too.
Yes, that sounds reasonable. We can mention these macros in
buildflags.md and advise packagers not to use them or change them.
The _distro_ prefix aligns with that as well.
Thanks,
Florian