Congratulations to the BuildXL team! Domino, incidentally, was/is the internal for BuildXL; there are a few papers published where the system is described under that name. I had the privilege to see it gradually rolled out in the Office codebase over the course of a year or two. It was a massive improvement, and the lengths to which the team went to see it through are really beyond description here.
I _have_ to wonder why we didn't just pick up Bazel, which is Google's open-source distributed build engine for large systems, which also happens to have been stable for years. Perhaps its Windows support wasn't up to snuff at the time, but it feels like that would have been easier to fix that than to build a whole new build system.
Regardless, congrats again! So cool to see this out in the open.
The why and how of this can be found here :
https://github.com/Microsoft/BuildXL/blob/master/Documentati...
Seems what drove this was a 90 build times of 90 hours for and end to end build of Office. What I can gather this has a means of capturing all read/write operations for a build step and placing it in a cache store to determine if a change necessitates the rebuild of a component. Since it can hook in at a lower level, it isn't sensitive to time stamps for building. Actually quite interesting
I interned with TSE in 2016 and had a blast. It is nice seeing one of their projects get open sourced.
“Its own internal scripting language, DScript, an experimental TypeScript based format used as an intermediate language by a small number of teams inside Microsoft”
Anyone else notice this?
Anyone know a bit more about DScript?
No Linux support, so who cares?
"BuildXL runs 30,000+ builds per day on monorepo codebases up to a half-terabyte in size with a half-million process executions per build... You may find our technology useful if you face similar issues of scale."
I know this wasn't supposed to be a humorous announcement but I couldn't help laughing out loud at that! Kudos to the managers at Microsoft who now seem to be asking "Why not?" instead of "Why should we?" when the topic of releasing code to the community is raised.