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'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 <<a = href=3D"mailto:[email protected]">[email protected]</a>> 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 <<a href=3D"mai= lto:[email protected]" target=3D"_blank">[email protected]</a>> = writes:<br> <br> > Is nproc enough to prevent disruption?=C2=A0 (I mean, should it be les= s than<br> > 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'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 "<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 "<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&sek= tion=3D1&format=3Dhtml" rel=3D"noreferrer" target=3D"_blank">https://ma= n.freebsd.org/cgi/man.cgi?query=3Dnproc&sektion=3D1&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 "sysctl -n hw.ncpu" 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> 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> > I'm usually not bothered by this so I don'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==--