Miro Hrončok wrote: > On 19. 06. 20 23:11, Ben Cotton wrote: > > All make invocations in spec files that don't use the install target will be > > modified to use the %make_build macro > > Many Python packages build Sphinx documentation with variant of "make html". > Such invocation will always be just 1 job. Hence there is no benefit of parallel > make. That's also the case in several Ada packages, where the makefile just assembles the command line for a single invocation of GPRbuild, and parallel compilation is handled by GPRbuild. I expect that there are many other more or less special cases. > Replacing it with %make_build will only make it harder to read. Especially in cases like "make check", where the purpose isn't to build anything but to run a testsuite. The word "make" is already less than ideal in those cases, and replacing it with the less well-known "make_build" will make it more confusing. > Can we exclude such cases? Or do we want all make invocations to be mecronized, > even if there is no benefit? So I too want that question answered. Also: Is it set in stone that "make_build" means "make in parallel" and nothing else? If so, why isn't the macro called "parallel_make"? Or is it the case that "make_build" means "the typical make command to use in a build stage", and a future version of the macro may include other parameters that are considered useful in a build stage but may not be appropriate for other use cases? In that case the macro should only be applied in the %build section, and any make invocation that looks less than typical should be left alone. Björn Persson
Attachment:
pgpiZOfqhWmHJ.pgp
Description: OpenPGP digital signatur
_______________________________________________ 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
