Bug 10684

Summary: Distributed build support
Product: [Build System, Metadata & Runtime] BitBake Reporter: Richard Purdie <richard.purdie>
Component: bitbakeAssignee: Unassigned <unassigned>
Status: NEW --- QA Contact:
Severity: enhancement    
Priority: Low CC: joshuagloe, poky.bs.watcher, poky.watcher, randy.macleod, ross.burton, tvgamblin
Version: 2.3   
Target Milestone: Future   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Yes (doc changes required)
Bug Depends on: 1560    
Bug Blocks:    

Description Richard Purdie 2016-11-16 13:38:48 UTC 
It would be nice if bitbake supported splitting the builds onto multiple different machines to allow the load to be distributed.

With the advent of multiconfig, this becomes something which is more desirable. It likely won't affect normal builds times too much due to the cross compiler creation still being the bottle neck in the build process, parallelisation doesn't help this.

The logical place in bitbake to handle this is at the bitbake-worker level. This communicates with the server over a pipe so doing this from a remote machine shouldn't be too different. With multiconfig we already support spawning multiple workers.

This bug has recipe specific sysroots as a prerequisite.
Comment 1 Richard Purdie 2020-05-02 03:01:07 UTC 
We now have recipe specific sysroots and working multiconfig. To make this work, we'd probably assume an NFS shared sstate that all the workers can pool sstate to and force all tasks for a given WORKDIR to run on a given host. The challenge would be ensuring multiple populate sysroot tasks execute on each worker to ensure the sstate is extracted.
Comment 2 Randy MacLeod 2023-10-24 14:24:39 UTC 
Bulk move from 4.99 or 0.00 to 5.99
Comment 3 Ross Burton 2025-10-23 15:13:01 UTC 
Do we just admit we're going to close this?