First thing every software engineer does after leaving Google is rewrite Blaze. Just like every site reliability engineer rewrites borgmon. What I chose to do myself was make Blaze happen using a Makefile config. There's a blog post somewhere where Google talks about why they switched from GNU Make to Blaze c. 2006. if I remember correctly it basically boiled down to not having strict dependency checking. So I thought, why not simply avoid their published mistakes without changing build systems? I learned everything I could about make, discovered that variables are secretly lambdas, and that enabled me to figure out a way to have a static archive package for each folder, which also avoided the need to write a makefile code generator. Then I wrote a simple C program to check incremental elf symbols so the build graph stays sanely formed. It totally got make working like a dream in a way I simply hadn't seen before. https://github.com/jart/cosmopolitan/blob/master/tool/build/...
Reading your words, it looks like you have made a kind of make replacement that just works. Following your link, it looks like... what ? I don't know, some tool that checks some build configuration, augments C and postprocesses executable files?
(Looking at https://github.com/jart/cosmopolitan it's an interesting hack. Might be useful in some cases, for example command-line tools like git.)
Have you made something that looks like a better make? If so, it would be nice to know more. Thanks.
Sorry here's what a build file looks like, which should hopefully clarify: https://github.com/jart/cosmopolitan/blob/master/libc/mem/me... As you can see, it's just vanilla make. The package program is just a helper that checks to make sure DIRECTDEPS variables are correct. That's the part Google said was tricky back in 2006. Have you ever seen people talk online about how it's super difficult to have a single makefile build multiple library files? Particularly static ones? Like the pitfalls of making sure the linker arguments are the correct order, or removing a dependency from one will break all the others that needed it transitively? This is how it can be done. I found out it just requires following a highly specific convention, where it's a little toilsome to type, but so rewarding once it's done. It also means I don't need to ask users to install a cutting edge build system to build my code, since I've just seen too much drama in that space.
A Google engineering manager once told me that “back in the day, SREs got promoted for writing monitoring systems, and so we ended up with a bunch of unsupported monitoring systems”
