Intermediate results of icecc (icecream) testing on Yocto
In the Yocto environment, icecc (icecream) can be used for parallel builds, and we are currently testing it to set up a workstation farm within the company. Since the testing isn’t fully complete, I’ve written a summary of the current status, issues, and areas for improvement. I’ll write a detailed blog post on configuring icecc later, so please stay tuned or try setting it up yourself with a quick Google search.
What is icecc (Icecream)?
IceCC (Icecream) is an open-source tool that accelerates compilation by distributing compile tasks across multiple computers. It is primarily used for large-scale software builds in Linux environments and can work alongside build systems like GNU make and CMake.
Key Features
- Distributed Compilation: Compiles are executed simultaneously across multiple network-connected computers, reducing build times.
- Scheduler Role: The icecc-scheduler allocates and manages distributed tasks, efficiently distributing compilation requests.
- Cross-Compilation Support: Compatible with various compilers, making it usable in cross-compilation environments.
- Auto Scaling: Dynamically allocates available system resources in the network to build at optimal speed.
- Monitoring: The icecc monitor command allows real-time tracking of distributed build progress and node activity.
Icecream is particularly useful for reducing build times in large projects like Yocto. It’s similar to distcc but offers more automation features and flexibility.
Current Status / Interim Results / Areas for Improvement
We are currently using a setup with four workstations. Icecc worked successfully and built the core-image-minimal on the Poky Kirkstone branch.
However, when building Yocto-based code used in actual product development, an error occurred during configuration when building clang-related components due to the -fno-diagnostics-show-caret option. The current version of icecc in Yocto does not support clang builds. Clang-related components can be added to the ICECC_RECIPE_DISABLE list, or by setting the ICECC_CARET_WORKAROUND variable to 1, you can prevent the -fno-diagnostics-show-caret option from being used across all components, including gcc. I recommend the former approach.
This limitation likely exists because the developer who implemented meta/classes/icecc.bbclass in Yocto to support icecc did not account for more edge cases, such as clang. Until icecc in Yocto officially supports clang, modifying the implementation to avoid automatically adding this option for clang builds will work. I plan to create a simple workaround and submit it upstream when I have time.
Additionally, I am considering modifying the implementation to support clang. Initial tests with one or two simple adjustments showed it didn’t work smoothly with clang, so more time is needed.
Ultimately, using the above two variables, I successfully completed all builds. Next, I plan to compare build times and evaluate the feasibility of setting up a workstation farm company-wide based on the data.
Applying this setup to CI doesn’t seem particularly beneficial, in my opinion, so I intend to hold off. One reason is that we’re currently paying for a cloud environment that must be running at all times. I am not yet convinced of the significant advantages over high-performance instance types, particularly regarding how to configure and manage multiple instances.
References
- https://www.youtube.com/watch?v=VpK27pI64jQ: Although it’s a 5-year-old resource, this video introduces how to use icecc with Yocto.
- https://github.com/JPEWdev/icecream-sundae: As shown in the video, this tool provides a UI to monitor the status of each workstation and check if icecc is running smoothly.