On Wed, May 29, 2019 at 04:32:41PM +0200, Rainer Orth wrote:
> > I'd prefer not to determine the CPU count at configure time, the build
> > directory can be on some network filesystem and tested sometimes on one
> > machine, sometimes on another one, hw can be upgraded etc.
>
> somewhat agreed for testing on one or the other system. However, build
> dirs tend to be short-lived in my experience (and usually local because
> at least I have found builds on NFS so incredibly slow as to avoid them
> like the plague) and hw upgrades are relatively rare.
>
> > So, something similar to what your patch does, but don't substitute the
> > actual
> > CPU count, but a command to determine the number of CPUs?
>
> I'm not convinced that would work reliably: you can easily have one set
> of commands on one machine, but a slightly different one on another. If
> we really want to go this route, that means extracting the autoconf
> macro's logic into a separate script and use that at make check time.
> Not sure if that's worth the effort, especially since we're not really
> interested in the exact number of cores, just small (<= 8) vs. large (> 8).
Ok, so can we do a middle-ground, instead of the current change to
Makefile.am just replace the two spots that do num_cpus=1 with
num_cpus=@CPU_COUNT@
and keep the getconf invocation in there? On Linux it will do what it used
to do, and on targets that don't support getconf _NPROCESSORS_ONLN it will
use a configure time determined value?
Jakub
