3 ms·
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 m
by jart 6y ago
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/package.c https://github.com/jart/cosmopolitan/blob/master/tool/build/...
- klodolph 6y agoEvery ex-Google SRE I know is glad they don’t have to deal with Borgmon anymore. I don't think it’s popular these days.
- jart 6y agoAll the more reason to invent something that improves upon it, since love it or not, it's a must have tool.
- klodolph 6y agoA 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”
- joshuamorton 6y agoNot really, it's barely used anymore. Monarch has replaced it for most situations.
- s_gourichon 6y agoReading 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 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.
- jart 6y agoSorry here's what a build file looks like, which should hopefully clarify: https://github.com/jart/cosmopolitan/blob/master/libc/mem/mem.mk 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.