On 06/20/2020 02:23 AM, Dan Čermák wrote: > Sorry about the empty email, I've hit send too fast… > > Anyway, on the topic of parallel builds: what is everyone's opinion on > adding the %limit_build macro from openSUSE (see: > https://build.opensuse.org/package/view_file/network:chromium/memory-constraints/memory-constraints.macros?expand=1)? > > tl;dr; %limit_build -m 1500 will set the number of parallel processes so > that if all of them consume 1500 MB of RAM at most, that they will not > OOM your worker (especially handy on workers with many cores, but not > much RAM). > I would be in favor of this. We run into this issue a lot when building the LLVM packages. -Tom > > Cheers, > > Dan > > Dan Čermák <dan.cermak@xxxxxxxxxxxxxxxxxxx> writes: > >> Ben Cotton <bcotton@xxxxxxxxxx> writes: >> >>> https://fedoraproject.org/wiki/Changes/UseMakeBuildInstallMacro >>> >>> == Summary == >>> This change will update all spec files in Fedora that use make and replace >>> the make invocations with either the %make_build or %make_install macros. >>> >>> == Owner == >>> * Name: [[User:tstellar| Tom Stellard]] >>> * Email: <tstellar@xxxxxxxxxx> >>> >>> >>> == 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 parallel >>> make will be disabled for that package by redefining the %_smp_mflags macro >>> 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 objections or >>> earlier if approved by the package maintainers. >>> >>> A script will be used to apply the necessary changes to the spec files, and >>> the result will be manually inspected before being merged. >>> >>> 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. >>> >>> * This will make it easier to enforce consistent build flag usage across >>> all of Fedora. >>> >>> == 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: [https://pagure.io/releng/issues/9533 #9533] >>> >>> * 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 == >>> End-users will not notice any changes. >>> >>> == Dependencies == >>> No real dependencies, each package can be updated independently. >>> >>> == Contingency Plan == >>> * Contingency mechanism: None. If not all packages are updated in time, >>> then the work can continue into the next release. >>> * Contingency deadline: All work will be done in the rawhide branch, and >>> will not be backported into the f33 branch once it is created, so whatever >>> gets done before the branch date will make it into the release. >>> * Blocks release? No >>> >>> == Documentation == >>> The packaging guidelines will be updated as described in the Scope Section. >>> >>> >>> >>> -- >>> Ben Cotton >>> He / Him / His >>> Senior Program Manager, Fedora & CentOS Stream >>> Red Hat >>> TZ=America/Indiana/Indianapolis >>> _______________________________________________ >>> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx >>> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxxxxxxxxxx >>> >>> >>> _______________________________________________ >>> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx >>> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx >>> 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
