Re: get-gauche.sh shouldn't use make -j without options

Shiro Kawai <[email protected]> Tue, 5 May 2026 21:58:24 -1000
Newsgroups gmane.lisp.scheme.gauche
Message-ID <CALN0JNEopP3DGd4nv=yg5tcK-kSg-ub8AYdDYbsKAazfnKDnpw@mail.gmail.com>
--===============6884619968740948019==
Content-Type: multipart/alternative; boundary="000000000000e1fa38065121877c"

--000000000000e1fa38065121877c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

OK, I pushed the fix.  If nproc isn't available, we just run -j without
value.



On Tue, May 5, 2026 at 7:55=E2=80=AFPM Jens Thiele <[email protected]> wrote:

> Shiro Kawai <[email protected]> writes:
>
> > Is nproc enough to prevent disruption?  (I mean, should it be less than
> > nproc to keep a few cores for other processes?
>
> nproc should be good enough. I also think my new audio setup using
> pipewire is more sensitive to this, than it used to be (imho ideally
> music wouldn't be interrupted no matter how high the system load is)
>
> Regarding portability:
>
> - on debian systems nproc is in the coreutils package which is described
>   as:
>   "
>   This package contains the basic file, shell and text manipulation
>   utilities which are expected to exist on every operating system.
>   "
>
> - looks like freebsd also has nproc (but is that installed by default?):
>   https://man.freebsd.org/cgi/man.cgi?query=3Dnproc&sektion=3D1&format=3D=
html
>
> did some more search and found:
>
> a)
> https://stackoverflow.com/questions/45181115/portable-way-to-find-the-num=
ber-of-processors-cpus-in-a-shell-script
> suggesting "sysctl -n hw.ncpu" on BSDs
>
> b)
> https://unix.stackexchange.com/questions/208568/how-to-determine-the-maxi=
mum-number-to-pass-to-make-j-option
> interesting read ... looks like there are machines with not enough RAM
> to run big compilations on all CPUs in parallel
> =3D> in debian there is even a package to guess the value for make -j:
>
> https://sources.debian.org/src/guess-concurrency/0%2B20250305/guess_concu=
rrency.py
>
> > I'm usually not bothered by this so I don't know.)
>
> so many CPUs?
>
>
> _______________________________________________
> Gauche-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gauche-devel
>

--000000000000e1fa38065121877c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:large">OK,=
 I pushed the fix.=C2=A0 If nproc isn&#39;t available, we just run -j witho=
ut value.</div><div class=3D"gmail_default" style=3D"font-size:large"><br><=
/div><div class=3D"gmail_default" style=3D"font-size:large"><br></div></div=
><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Tue, May 5, 2026 at 7:55=E2=80=AFPM Jens Thiele &lt;<a =
href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">Shiro Kawai &lt;<a href=3D"mai=
lto:[email protected]" target=3D"_blank">[email protected]</a>&gt; =
writes:<br>
<br>
&gt; Is nproc enough to prevent disruption?=C2=A0 (I mean, should it be les=
s than<br>
&gt; nproc to keep a few cores for other processes?<br>
<br>
nproc should be good enough. I also think my new audio setup using<br>
pipewire is more sensitive to this, than it used to be (imho ideally<br>
music wouldn&#39;t be interrupted no matter how high the system load is)<br=
>
<br>
Regarding portability:<br>
<br>
- on debian systems nproc is in the coreutils package which is described<br=
>
=C2=A0 as:<br>
=C2=A0 &quot;<br>
=C2=A0 This package contains the basic file, shell and text manipulation<br=
>
=C2=A0 utilities which are expected to exist on every operating system.<br>
=C2=A0 &quot;<br>
<br>
- looks like freebsd also has nproc (but is that installed by default?):<br=
>
=C2=A0 <a href=3D"https://man.freebsd.org/cgi/man.cgi?query=3Dnproc&amp;sek=
tion=3D1&amp;format=3Dhtml" rel=3D"noreferrer" target=3D"_blank">https://ma=
n.freebsd.org/cgi/man.cgi?query=3Dnproc&amp;sektion=3D1&amp;format=3Dhtml</=
a><br>
<br>
did some more search and found:<br>
<br>
a) <a href=3D"https://stackoverflow.com/questions/45181115/portable-way-to-=
find-the-number-of-processors-cpus-in-a-shell-script" rel=3D"noreferrer" ta=
rget=3D"_blank">https://stackoverflow.com/questions/45181115/portable-way-t=
o-find-the-number-of-processors-cpus-in-a-shell-script</a><br>
suggesting &quot;sysctl -n hw.ncpu&quot; on BSDs<br>
<br>
b) <a href=3D"https://unix.stackexchange.com/questions/208568/how-to-determ=
ine-the-maximum-number-to-pass-to-make-j-option" rel=3D"noreferrer" target=
=3D"_blank">https://unix.stackexchange.com/questions/208568/how-to-determin=
e-the-maximum-number-to-pass-to-make-j-option</a><br>
interesting read ... looks like there are machines with not enough RAM<br>
to run big compilations on all CPUs in parallel<br>
=3D&gt; in debian there is even a package to guess the value for make -j:<b=
r>
<a href=3D"https://sources.debian.org/src/guess-concurrency/0%2B20250305/gu=
ess_concurrency.py" rel=3D"noreferrer" target=3D"_blank">https://sources.de=
bian.org/src/guess-concurrency/0%2B20250305/guess_concurrency.py</a><br>
<br>
&gt; I&#39;m usually not bothered by this so I don&#39;t know.)<br>
<br>
so many CPUs?<br>
<br>
<br>
_______________________________________________<br>
Gauche-devel mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Gau=
[email protected]</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/gauche-devel" rel=
=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/listi=
nfo/gauche-devel</a><br>
</blockquote></div>

--000000000000e1fa38065121877c--


--===============6884619968740948019==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============6884619968740948019==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gauche-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gauche-devel

--===============6884619968740948019==--