< Changes
(→Scope) |
|||
| Line 123: | Line 123: | ||
== Scope == | == Scope == | ||
* Proposal owners: | * 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) | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Other developers: | * 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. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
| Line 133: | Line 133: | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
* Policies and guidelines: | * 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. <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | <!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | ||
Revision as of 21:22, 16 June 2020
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.
Feedback
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
N/A (not a System Wide Change)
How To Test
N/A (not a System Wide Change)
User Experience
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)