DSB wrote:
> Isn't nproc or nproc+1 too much? On systems with hyper-threading,
> this will try using too many jobs, and might cause the system be
> significantly less responsive. Maybe nproc/2 is a better default?
>
>
> This is an interesting question and I suppose the answer depend
cont...@zhengqiu.net wrote:
> Hello,
>
> While we are doing development with Yocto Project (1), a source-
> based Linux distro builder, we found that many instances of making
> running in parallel with other work can overload even a large
> many-core build machine. Existing mechanisms that are ei
Herring, Daniel - 0447 - MITLL wrote:
> On Jun 26, 2022, at 3:30 PM, Eli Zaretskii wrote:
>
> How do people bootstrap systems nowadays? Is it only via
> cross-compilation?
>
>
> Another way to bootstrap is to have a native tool chain that is less
> capable…. For example, an embedded device ma
Paul Smith wrote:
> On Fri, 2021-08-13 at 14:14 +0100, Howard Chu via Bug reports and
> discussion for GNU make wrote:
>> I'm looking for a way to expose a job ID number to the individual
>> jobs, in a consecutive range from 1-[number of jobs]. Not just
>> unique nu
he range of 9000-9020. On a build/test machine we don't worry
about conflicts,
a developer has no business running conflicting software at the same time as
building/testing
our software. And of course, the baseport 9000 can be moved at will.
>
> Christian
>
> On Fri, Aug 13
In my original jobserver implementation, I filled the job pipe with
up to 256 bytes, numbers from 0-255. The idea being that then make
could distinguish each job with a unique ID number. That idea got
thrown away when we decided to raise the limit to PIPEBUF (4096 on
traditional Unix, much larger n
