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)

    • The Making sure you're not a bot! will be updated to document this macro
    • The Fedora packaging policy will be updated to state that packages that want to use additional flag SHOULD use the new macros.

  • 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.

6

This change proposal has now been submitted to FESCo with ticket #3429 for voting.

To find out more, please visit our Changes Policy documentation.

7

There are already alot of RPM macros to wrestle with. I see this proposal is specific to a specific type of toolchain, but still adding to the set of RPM macros and not replacing or deleting any, correct?

Could conflicting options happen when mixed in with the other macros? Would that result in FTBFS state?

Could these options be used to produce a binary that isn’t what’s targeted for a Fedora release? e.g. Fedora touts using specific, better (?), more performant (and debug) options…

I guess I feel that Fedora’s toolchain RPM macros are pretty good and good enough to encourage projects to meet them.

But I can also see exceptions. Do you have a specific example in mind or encountered?

Does this proposal make it easier to understand if/when things break b/c of these new macros?

8

That is possible. It’s always up to the maintainer to take care of such issues. Without those macros, the maintainer would use some other mechanism to modify the flags, e.g. set an appropriate shell variable. In that case, they too would be responsible for figuring out what flags to add. The macros just make it easier to add new flags, they don’t change the need to figure out what flags those are.

Packaging Guidelines specify which flags should be used by default, and when they can be modified. Wrong flags could be used, it’s the responsibility of the maintainer to follow the guidelines and only introduce changes when beneficial or required because of package-specific reasons.

1 Like
9

I see this proposal is specific to a specific type of toolchain, but still adding to the set of RPM macros and not replacing or deleting any, correct?

Correct.

Simple grep from the SPECfile tarball found several thousand occurrences in various packages:

# grep -e "CFLAGS" -e "CPPFLAGS" -r rpm-specs | wc -l
3319

so the build flags manipulations is definitively not uncommon.

The problem is (I haven’t checked yet, but from my research on how we utilize the build flags in various macros) that most of them are at least bug-prone.

I am just adding a standardized way, that would be correctly propagated to all macros and all build stages (something a simple export can´t manage).
And I aim to elegantly solve a number of existing bugs with that.

10

This change has been accepted by FESCo for Fedora Linux 43. A full list of approved changes to date can be found on the Change Set Page.

To find out more about how our changes policy works, please visit our docs site.

11

I proposed a pull request with the changes:
PR#336: [Fedora 43 Change] Add new set of '_pkg_extra_***flags' build macros - rpms/redhat-rpm-config - src.fedoraproject.org
it also contains documentation

12

The change is now functionally complete, and present in production (Fedora Rawhide).

I updated the BZ ticket and the Change page accordingly.

The only remaining step is the update of the Fedora Packaging Guidelines, which I proposed here.

13

The Fedora Packaging Guidelines has been updated.

This change is now FULLY COMPLETE.