When building release binaries in the Guix environment, the depends native packages, namely native_capnp, native_libmultiprocess, and native_qt, are currently built for every target host. This results in a needless expenditure of Guix builders’ compute resources.
One possible improvement is to build these native packages as part of a Guix profile instead.
Pros:
-
Speeds up the depends build process across all hosts by roughly 20%, significantly reducing resource consumption for builders.
-
Removes the need to expose the native build toolchain to the cross-compilation build environment, which improves security and build isolation.
Cons:
- The Guix manifest file will need to be updated to maintain three new package definitions.
Alternative Approach:
As an alternative, the depends build subsystem could be restructured to share and reuse native packages across hosts where possible. This would eliminate the need to modify the Guix manifest and might provide some benefit to developers building depends locally. However, local builders already benefit from an effective built-package cache.
Additionally, the effectiveness of this alternative could be undermined when using LLVM-only build profiles for macOS targets.
Conclusion:
There is clear room to optimize the release build process, which relies heavily on volunteer computing resources. I believe the performance gains and isolation improvements are well worth the extra complexity and maintenance burden introduced to the Guix manifest.
I am posting this RFC to gather conceptual feedback and opinions on this approach.
