Re: Fedora 33 System-Wide Change proposal: Use %make_build and %make_install macros

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux