F43 Change Proposal: Package specific RPM Macros For Build Flags (system-wide)

Project Discussion Change Proposals
,
1

Package specific RPM Macros For Build Flags

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Create “extra flag” macros to make it easier for packages to add to the default list of compiler flags.

This is a follow up to the: Changes/RPMMacrosForBuildFlags - Fedora Project Wiki

:link: Owner

:link: Detailed Description

The macros file in the redhat-rpm-config package contains a list of default compiler flags for packages to use when compiling C, C++, and Fortran packages. This change will add new macros to redhat-rpm-config which will make it easier for packages to add their own compiler flags.

The proposed macros for adding new flags are:

%_pkg_extra_cflags %_pkg_extra_cxxflags %_pkg_extra_fflags %_pkg_extra_ldflags

These will be added to %{build_cflags}, %{build_cxxflags}, %{build_fflags}, and %{build_ldflags} respectively to allow packages to add their own flags to the default list: e.g.

%build_cflags %{optflags} %{_pkg_extra_cflags}

Note:
This is a followup for the previously accepted change:

that was implemented as:

but later changed to:

My goal is to re-implement the original solution, which would create the _pkg_extra macros, to grant the package maintainers an elegant, clean and simple way to make the per-package adjustments to the build flags.

Currently, this is done by editing the CFLAGS etc. environmental variables directly and re-exporting them. That sometimes cause issues that could be avoided by using macro instead.

Also, when set by macro, the flags adjustment will be present in every ‘%set_build_flags’ call, not just in-between of the manual adjustment and the end of the RPMbuild phase (%build, %install, %check, etc.).

:link: Feedback

:link: Benefit to Fedora

  • It will provide a standard way to add to the list of default compiler flags.
  • It will make it easier to determine which packages 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.

:link: Scope

  • Proposal owners:

    • Proposal owners will update the redhat-rpm-config package and add the new macros.
    • Proposal owners will test the changes to ensure that the correct flags are still being used.

  • Other developers:

    • Other developers may, but are not required to, update their packages to use the new macros.

  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

None.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? Y/N

:link: How To Test

  • This can be tested by inspecting the value of the %{build_cflags}, %{build_cxxflags}, %{build_fflags}, and %{build_ldflags} and ensuring they are the same before and after the change.
  • This can be tested by modifying some of the new macros in a spec file and ensuring that the changes appear in the appropriate macro mentioned above.

:link: User Experience

This is a change for developers and will have no impact to the user experience.

:link: Dependencies

A PR must be approved and merged to the ‘redhat-rpm-config’ package. A PR must be approved and merged to the Fedora Packaging Guidelines.

:link: Contingency Plan

  • Contingency mechanism: Change owner will revert the update to redhat-rpm-config.

  • Contingency deadline: Beta freeze

  • Blocks release? No

:link: Documentation

need to be done

N/A (not a System Wide Change)

:link: Release Notes

None.

Last edited by @amoloney 2025-06-02T20:43:32Z

Last edited by @amoloney 2025-06-02T20:43:32Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

This feels pretty pointless and unnecessary, we already have %_distro_extra_cflags already.

4

The distro prefix of those macros indicates to me they are for distribution wide settings. I would hesitate to set them if I need some flag in a particular package.

5

Hi,
these flags have a specific use case, that directly conflicts with the one I propose.

The %_distro_extra_cflags are meant specifically for Linux distributions derived from Fedora, so they have an easy way to add their custom system-wide default build flags.

They can’t be used for per-package settings, as this would collide in every case where someone would need them for both cases.

I discussed this specifically with the author of the original change and I only submitted this change after I verified the existing macros are not sufficient.

–

I will propose an update to the readme to explain this difference.