On Thu, Aug 12, 2021 at 06:14:57PM -0700, Michel Alexandre Salim via devel wrote: > On Thu, Aug 12, 2021 at 05:23:18PM -0700, Michel Alexandre Salim via devel wrote: > > On Wed, Aug 11, 2021 at 10:56:39AM +0300, Panu Matilainen wrote: > > > On 8/10/21 8:53 PM, Ankur Sinha wrote: > > > > On Thu, Aug 05, 2021 09:01:14 +0200, Miroslav Suchý wrote: > > > > > Dne 05. 08. 21 v 2:42 Michel Alexandre Salim via devel napsal(a): > > > > > > This is now implemented on Rawhide; Fedora updates are in testing: > > > > > > > > > > Where is it documented? > > > > > > > > > > I suggest one of these > > > > > > > > > > https://rpm-packaging-guide.github.io/ > > > > > https://docs.fedoraproject.org/en-US/packaging-guidelines/ > > > > > > > > That would be great. I was trying to put %limit_build at the top of my > > > > spec and kept getting errors. Then I looked at the mcrouter spec and > > > > realised this needs to go into the %build section XD > > > > > > Yes, the macro is a strange as it mixes rpm macro language and shell > > > language, relying on some rather subtle aspects of how spec parsing and > > > macros work and has to be placed in a shell section. If you ask me, it's > > > asking for trouble. > > > > > > Setting RPM_BUILD_NCPUS environment should achieve the same without > > > requiring the twisty %global override which looks like it may break > > > _smp_build_ncpus use in later sections (but I may be missing something > > > there) > > > > > So - I did try exporting RPM_BUILD_NCPUS earlier, and having tried it > > again, could not figure out how to set that definition from within a > > macro. Any idea? > > > > openSUSE's macro overrides %_smp_mflags instead, which ... seems to work > > for them, but I agree that we should rather use an environment variable instead. > > > Some findings: > - overriding %_smp_mflags works. But I have to use %global - %define > does not work - and that triggers some ugly warnings at every build > - setting RPM_BUILD_NCPUS (or, similarly, %_smp_ncpus_max) does not work > since %_smp_build_ncpus is already defined by then > > Seems like the proper fix here is to either: > - try and get this macro into RPM proper, so we can have %limit_build > declared at the top of the spec. This will likely push the change back > to F36 at the earliest, and would make it hard to retrofit on existing > releases, unless we want to carry out-of-tree patches. > - _smp_build_ncpus also seems to be defined per platform, even though > the definition is mostly identical, so this will be a bit messy > - change the usage, and require users who want to limit the build to do > something like this: > > %make_build %{limit_build -m 4096} -- with %limit_build used as a > %function that spits out the relevant -j override > Updated pull request, using the latter option: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/141 The macro is now rewritten in Lua, since I can't coerce the shell definition to just output a value. Tested locally with mock (I had to copy fedora-34-x86_64 to fedora-35-x86_64 as the Rawhide target is currently failing on GPG verification). - if limit_build computes a number that is higher than %_smp_build_ncpus it outputs nothing - if it computes a value that is smaller, it outputs '-j<thatvalue>' - if it computes a value less than 1 it outputs '-j1' Tested with mcrouter locally and setting the memory requirement to some ridiculous value (-m 409600) I do end up with a single-core build. Inline documentation is provided, once the PR is reviewed and this is built for Rawhide I'll update the packaging guideline. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/michel@xxxxxxxxxxxxxxx
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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure