<div dir="auto">Personally, I would rather use the default of the build system (unless it's broken, like when we need to specify -j1 to override parallelism during the build process) and allow the user to override that when desired. <div dir="auto"><br></div><div dir="auto">Developers tend to code based on the completely l compilers, and if we start overriding the defaults as a standard, it opens of the chances of breaking compilations.<br><div dir="auto"><br></div><div dir="auto">This is my opinion as a random SBo user (with almost 200 packages I maintain) and not an SBo admin.</div><div dir="auto"><br></div><div dir="auto">Jeremy</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Mar 12, 2026, 1:12 AM Lumin Etherlight via SlackBuilds-users <<a href="mailto:slackbuilds-users@slackbuilds.org">slackbuilds-users@slackbuilds.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">fsLeg via SlackBuilds-users<br>
<<a href="mailto:slackbuilds-users@slackbuilds.org" target="_blank" rel="noreferrer">slackbuilds-users@slackbuilds.org</a>> writes:<br>
<br>
> This is actually frowned upon on SBo specifically<br>
> due to overriding MAKEFLAGS.<br>
<br>
        It wouldn't be hard to define MAKEFLAGS only<br>
  if it's not already defined  by the user.  Or, for<br>
  more flexibility,  prepend the default -j  flag to<br>
  MAKEFLAGS, like:<br>
<br>
  MAKEFLAGS="-j $(nproc --ignore=1) $MAKEFLAGS"<br>
<br>
  This way, if the user  defines other flags, our -j<br>
  will still be  added.  If the user adds  a -j flag<br>
  of their  own, it  would override the  previous -j<br>
  flag as latter -j options take precedence.<br>
<br>
        I think  the average  user should  not worry<br>
  about setting MAKEFLAGS or the number of jobs; the<br>
  maintainer should provide reasonable defaults.  If<br>
  the package  is big, I  don't expect it to  take a<br>
  day to build  when it could have built  in half an<br>
  hour, but I  also expect builds to not  lock up my<br>
  machine while I'm using  it (some SlackBuilds seem<br>
  to use  nproc then  /add/ to  the total  number of<br>
  jobs, instead of subtracting).<br>
<br>
<br>
Best Regards,<br>
Lumin Etherlight<br>
_______________________________________________<br>
SlackBuilds-users mailing list<br>
<a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank" rel="noreferrer">SlackBuilds-users@slackbuilds.org</a><br>
<a href="https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" rel="noreferrer noreferrer" target="_blank">https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
Archives - <a href="https://lists.slackbuilds.org/pipermail/slackbuilds-users/" rel="noreferrer noreferrer" target="_blank">https://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
FAQ - <a href="https://slackbuilds.org/faq/" rel="noreferrer noreferrer" target="_blank">https://slackbuilds.org/faq/</a><br>
<br>
</blockquote></div>