Anders Andersson wrote in
 <CAKkunMaMrze9aHt5Ao7A6mdJ=YTa4MUAUc=WNe+0f=UrZaaAvQ@mail.gmail.com>:
 |On Sat, Feb 22, 2025 at 4:29 PM Marc Espie <marc.espie.openbsd@gmail.com> \
 |wrote:
 |>
 |> I had quite a bit of fun with students this week, and stumbled upon
 |> getopt ::   extension.
 |>
 |> Figured out, it would be obvious to do in make.
 |>
 |> I looked at the others (very few instances) of tools that use ::
 |> to discern a pattern: in general, the consensus is that if we get an
 |> optarg, we whine if it doesn't match our expectation.
 |>
 |> So here's a patch to have make -j use hw.ncpuonlines if there's no \
 |> optarg.
 |> Might come in handy for people compiling on several machines who don't
 |> want to remember the details.
 |>
 |> Wrt posix's compatibility, opengroup doesn't say anything.
 |>
 |> And gmake -j does something (doesn't limit the number of jobs, from \
 |> the doc)
 |>
 |>
 |> So, handy ? crazy ? not needed ?
 |
 |gmake -j does indeed run EVERYTHING in parallel, which can work in
 |many cases on small projects but it is a crazy default. I wonder if
 |it's designed to be used with distcc.

Paul Smith, the author, said

  This option of "-j" with no arguments IS commonly used by GNU Make
  users so it can't be changed now.  But you're right, it doesn't make
  much sense to use by itself except in trivial makefiles where you know
  that it's not possible to get large numbers of parallel jobs.

  Instead, it's used with -l; for example:

     make -j -l4

  This is arguably a much more reasonable way to handle parallelism
  anyway, than using a fixed number of jobs.  Although of course it's
  still dependent on the number of cores to get the right value, due to
  the way load is calculated on POSIX systems.

Where that is

 -l [load], --load-average[=load]
      Specifies that no new jobs (commands) should be  started  if  there
      are  others  jobs  running and the load average is at least load (a
      floating‐point number).  With no argument, removes a previous  load
      limit.

However, he also said

  I also agree that optional arguments like this are a design mistake.  I
  don't think we should ask POSIX to perpetuate it by making <maxjobs>
  optional.

  Previously I recommended using a special value, such as "-j0", to mean
  "best guess".  Or, we can allow word arguments like "-j nproc" or
  similar in addition to integer values; even math like "-j nproc+2" or
  "-j nproc-1" or something.

  But simple "make -j" with no argument choosing some value, whether
  based on hardware or defaulted, isn't going to work for GNU Make.

Also to note that nproc[-1/xx] may work on OpenBSD, but on Linux,
in at least namespaces, it may give wrong values (<> cgroup).

What would really rock my/the house would be an interface that can
be queried easily, which would give a guess.
Ie, something i could register at and say "during my lifetime,
i would love to have X threads running in parallel, and it would
then hand out a value to me.  Maybe even with an additional, "and
what value can i have now" thing.
(Ie, GNU make has this jobmanager, which could update its state
and furtherly act accordingly.)

 |Using the number of CPUs is of course a far better and more intuitive
 |option, and what I first assumed gmake did until I read the docs more
 |carefully and tried it on a larger project...

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
|
|In Fall and Winter, feel "The Dropbear Bard"s pint(er).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear