On Thu, May 30, 2019 at 10:59:59AM +0200, Rainer Orth wrote:
> this version does this and passed the same testing as the previous one.
> Ok for mainline now?
>
> Thanks.
> Rainer
>
> --
> -
> Rainer Orth, Center
Hi Jakub,
>>> > 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 diffe
Hi Jakub,
>> > 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 o
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
Hi Jakub,
> On Wed, May 29, 2019 at 04:13:41PM +0200, Rainer Orth wrote:
>> Prompted by extremely long libgomp make check times due to missing
>> parallelism, I noticed that the current support to restrict testcase
>> parallelism only works on targets which have getconf _NPROCESSORS_ONLN.
>> Inste
On Wed, May 29, 2019 at 04:13:41PM +0200, Rainer Orth wrote:
> Prompted by extremely long libgomp make check times due to missing
> parallelism, I noticed that the current support to restrict testcase
> parallelism only works on targets which have getconf _NPROCESSORS_ONLN.
> Instead of adding spec
Prompted by extremely long libgomp make check times due to missing
parallelism, I noticed that the current support to restrict testcase
parallelism only works on targets which have getconf _NPROCESSORS_ONLN.
Instead of adding special cases for all sorts of tools to determine the
number of cores, I