For core system development, it is often best to have the build system itself available on the developer workstations so developers can run their own builds and directly rebuild the software stack. You should keep the core system unchanged as much as possible and do your work in layers on top of the core system. Doing so gives you a greater level of portability when upgrading to new versions of the core system or Board Support Packages (BSPs). You can share layers amongst the developers of a particular project and contain the policy configuration that defines the project.
Aside from the previous best practices, there exists a number of tips and tricks that can help speed up core development projects:
Use a Shared State Cache (sstate) among groups of developers who are on a fast network. The best way to share sstate is through a Network File System (NFS) share. The first user to build a given component for the first time contributes that object to the sstate, while subsequent builds from other developers then reuse the object rather than rebuild it themselves.
Although it is possible to use other protocols for the sstate such as HTTP and FTP, you should avoid these. Using HTTP limits the sstate to read-only and FTP provides poor performance.
Have autobuilders contribute to the sstate pool similarly to how the developer workstations contribute. For information, see the "Autobuilders" section.
Build stand-alone tarballs that contain
"missing" system requirements if for some reason
developer workstations do not meet minimum system
requirements such as latest Python versions,
chrpath
, or other tools.
You can install and relocate the tarball exactly as you
would the usual cross-development toolchain so that
all developers can meet minimum version requirements
on most distributions.
Use a small number of shared, high performance systems for testing purposes (e.g. dual, six-core Xeons with 24 Gbytes of RAM and plenty of disk space). Developers can use these systems for wider, more extensive testing while they continue to develop locally using their primary development system.
Enable the PR Service when package feeds need to be incremental with continually increasing PR values. Typically, this situation occurs when you use or publish package feeds and use a shared state. You should enable the PR Service for all users who use the shared state pool. For more information on the PR Service, see the "Working With a PR Service".