Changes/UseMakeBuildInstallMacro

Comments and Explanations
The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.

Use make_build and make_install macros

Summary

This change will update all spec files in Fedora and replaces all uses of make with either the %make_build or %make_install macros.

Owner

• Name: Tom Stellard
• Email: <tstellar@redhat.com>

Current status

• Targeted release: Fedora 33
• Last updated: 2020-06-16
• FESCo issue: <will be assigned by the Wrangler>
• Tracker bug: <will be assigned by the Wrangler>
• Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The goal of this change is to standardize the usage of make in Fedora. All make invocations in spec files that don't use the install target will be modified to use the %make_build macro, and all make invocations that use the install target will be updated to use the %make_install macro. Any additional arguments to make that are not included in either the %make_build and %make_install will be preserved.

The %make_build macro enables parallel make builds using the -j option. In case a package does not build correctly with parallel make, then the the %_smp_mflags macro will be redefined in the spec file, like this:

 %global _smp_mflags -j1

All changes will be submitted to dist-git repositories via pull requests. Pull requests will be merged after 1 week if there are no objects or early if approved by the package maintainers.

All packages updated by this change request will be rebuilt after the spec file changes are merged.

Some packages already use the %make_build and %make_install macros. These packages will be left unchanged.

Benefit to Fedora

• Reduced build times: Using the %make_build macros enables parallel make builds which will reduce build times for Fedora packages.

Scope

• Proposal owners: Update spec files and submit pull requests and do new package builds. Optional: Merge pull requests (Proposal Owner would need to request to be added to provenpackagers group)

• Other developers: Package owners may merge pull requests and submit new builds if they want, but this is not required for them. A member of the provenpackagers group will be needed to merge pull requests.

• Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)

• Policies and guidelines: Package guidelines already specify that packages should use these macros when possible. Documentation will be updated to clarify that %make_build should be used for all make invocations (besides make install), and also with instructions for packages that fail to build with parallel make.

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

Upgrade/compatibility impact

No impact.

How To Test

Updated packages will be build tested using the koji-simple-ci test that is automatically run when a new pull request is created.

Dependencies

N/A (not a System Wide Change)

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
• Contingency deadline: N/A (not a System Wide Change)
• Blocks release? N/A (not a System Wide Change), Yes/No
• Blocks product? product

Documentation

N/A (not a System Wide Change)