* 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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to