zapcc
gg
| zapcc | gg | |
|---|---|---|
| 4 | 5 | |
| 1,238 | 985 | |
| - | 0.0% | |
| 1.8 | 0.0 | |
| almost 4 years ago | about 1 year ago | |
| C++ | C++ | |
| GNU General Public License v3.0 or later | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
zapcc
- In 10 years, Clang has become 2x slower, but generates code that is 10-20% faster
-
"Fast Kernel Headers" Tree -v1: Eliminate the Linux kernel's "Dependency Hell"
C++ modules helps with the parsing problem similar to precompiled headers, but it doesn't help with the code execution at compile time problem. All your overload matching, free function lookup, SFINAE, concept matching, and consteval code needs executing and that can take very considerable time. Other than JITing all that stuff, and maybe running an in-memory server like https://github.com/yrnkrn/zapcc, I don't know what more can be done here.
- Zapcc: A caching C++ compiler based on Clang
-
Distcc – distribute builds across multiple machines simultaneously
If you use clang, that might be of interest: https://github.com/yrnkrn/zapcc
gg
-
Migrating Your Open Source Builds Off Of Travis CI
Another interesting option if you are feeling adventurous is using AWS lambda as your build executor. I have no idea how feasible this is, however, the gg project from Stanford looks interesting. It attempts to use AWS lambdas for running builds at the maximum possible parallelism.
- Gg – The Stanford Builder
-
Building LLVM in 90 seconds using Amazon Lambda
This is very similar to https://github.com/StanfordSNR/gg by Keith Weinstein's group at Stanford. Cool stuff! Have always wondered why Keith's work hasnt made its way into large companies (besides I think Facebook? not sure)
- Comments About Build Systems and CI Services
-
Distcc – distribute builds across multiple machines simultaneously
Running it locally will always be faster as long as your machine is not a bottleneck (#cores, ram, ...). I think the use-case for distcc et al is to enable less-powerful machines to run builds faster by levering other machines. That’s exactly what we use it for at work. Our developers have not-so-powerful laptops and with distcc/icecc they can utilize the power of our build agents in the server room.
Also interesting to read: https://github.com/StanfordSNR/gg
What are some alternatives?
termux-ndk - android-ndk for termux
icecream - Distributed compiler with a central scheduler to share build load
sccache - Sccache is a ccache-like tool. It is used as a compiler wrapper and avoids compilation when possible. Sccache has the capability to utilize caching in remote storage environments, including various cloud storage options, or alternatively, in local storage.
ayanami-nemesis-analyzer - A C/C++ Staitc Analyzer for Now.
Buildkite - The Buildkite Agent is an open-source toolkit written in Go for securely running build jobs on any device or network
lua-clang - Build dynamic clang library for lua
Phoenix - Peace of mind from prototype to production
ClangBuildAnalyzer - Clang build analysis tool using -ftime-trace
opencilk-project - Monorepo for the OpenCilk compiler. Forked from llvm/llvm-project and based on Tapir/LLVM.
codebrowser - Woboq CodeBrowser
include-what-you-use - A tool for use with clang to analyze #includes in C and C++ source files