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

B. Watson urchlay at slackware.uk
Fri Jan 12 20:45:51 UTC 2024



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?


More information about the SlackBuilds-users mailing list