[Slackbuilds-users] Issues with webkit2gtk / webkit2gtk4.1 in a Slackware 32 bit

[Charadon]

We could go even simpler, and just have an environment variable called 
JOBS that gets applied, and then if it's not defined, use the original 
method of using half of the cores. So the code would look like:

`-j${JOBS:-"$(expr "$(nproc)" / 2 + 1)"}`

On 1/12/24 8:45 PM, B. Watson wrote:
>
>
> On Fri, 12 Jan 2024, Christoph Willing wrote:
>
>> Is this idiom a thing that sbolint could check for and warn about (or 
>> fail)?
>
> It could... though, it's complex enough that it might not be all that 
> reliable.
>
> Also consider... The original code was:
>
> "${NINJA:=ninja}" -j$(expr $(nproc) / 2)
>
> But this actually would have been OK and not resulted in "-j0" on a 
> single-proc
> system:
>
> "${NINJA:=ninja}" -j$(expr $(nproc) / 2 + 1)
>
> That would have done what the author intended: use half the available
> cores, or 1 core on a single-core box.
>
> Possibly sbolint could just warn if it sees -j passed to ninja at all
> (not an error, just a "make sure this does what you expect" kind of
> thing).
>
>> I thought using -j option like this in SBo SlackBuilds was banned (or 
>> at least highly discouraged).
>
> For make, that's true. The only 'approved' use of -j for make is -j1, for
> stuff that fails to build with parallelism.
>
> Reading up a bit on ninja... without the -j, its default number of jobs
> is based on the number of cores. On mine, with 8 cores, "ninja --help" 
> says:
>
>   -j N     run N jobs in parallel (0 means infinity) [default=10 on 
> this system]
>
> So there's theoretically no need for a MAKEFLAGS-like setting for ninja.
>
> In practice, for large projects like webkit2gtk, the limiting factor
> becomes virtual memory (RAM + swap). If I don't have enough memory to
> support 10 jobs, the build fails. Whoever added the -j$(expr $(nproc) 
> / 2)
> to webkit2gtk was probably trying to avoid running out of
> memory... ninja doesn't have an environment variable to set options
> like make does, or else it could have just been a comment in the
> README. Sigh.
>
> Personally, I like the idea of having a ninja-using SlackBuild grab
> the -jN option from MAKEFLAGS in the environment, to give the user
> some control that's otherwise lacking. But I wouldn't try to make that
> a requirement for everyone else.
>
> Another idea, we could define our own NINJAFLAGS. Code in the SlackBuild
> would be simple:
>
> "${NINJA:=ninja}" $NINJAFLAGS
>
> That could become part of meson.template.
>
> Opinions?
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/