On 06/22/2020 10:14 AM, Neal Gompa wrote:
> On Mon, Jun 22, 2020 at 11:51 AM Tom Stellard <tstellar@xxxxxxxxxx> wrote:
>>
>> On 06/20/2020 11:20 AM, Neal Gompa wrote:
>>> On Sat, Jun 20, 2020 at 2:16 PM Zbigniew Jędrzejewski-Szmek
>>> <zbyszek@xxxxxxxxx> wrote:
>>>>
>>>> On Fri, Jun 19, 2020 at 05:11:43PM -0400, Ben Cotton wrote:
>>>>> 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
>>>>
>>>> That is rather unwiely, in particular because it's quite common for
>>>> just *some* make invocations to fail in parallel mode. (E.g. the main
>>>> build works, but doc build fails, or install, etc.)
>>>>
>>>> Why not specify the override for the individual invocation:
>>>> %make_build -j1
>>>> %make_install -j1
>>>> %make_build -C docs -j1
>>>>
>>>
>>> I think I'd be more comfortable with making all "make %{?_smp_mflags}"
>>> calls switch to "%make_build" and leaving the rest alone.
>>>
>>
>> Is this because you are concerned about build failures caused by
>> enabling parallel builds for packages that aren't currently using
>> that?
>>
>
> Yes, and because Make is often used for non-compilation things and
> those aren't necessarily multi-threaded, and passing mflags there can
> break things.
>
>
If replacing 'make %{?_smp_mflags}' with %make_build is the only change
that is done, then I don't think this change proposal would be worth
doing. This would eliminate one of the benefits (increased build parallelism),
and also not help that much with the other stated benefit of enforcing
consistent build flag usage, since many packages would sill be using just 'make'.
Another possible solution to the issues you raise would be to restrict the
scope of this proposal to only make 'build', check, and install targets.
-Tom
_______________________________________________
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
