That's really cool. Fascinating to think about all the problems that get missed due to poor or missing visualizations like this.

I did a lot of work to improve the Mozilla build system a decade ago where I would have loved this tool. Wish they would have said what problem they found.

Is there a tool that records the timestamp of each executed command during a build, and when you rebuild, it tells you how much time is left instead of "building obj 35 out of 1023" ?

Or (for cmake or ninja) use a CSV that says how long each object takes to build and use it to estimate how much is left ?

but why? I have to admit it's a fun project

Looks like a general `fork()` visualizer to me. Which is great!

Amazing! Great job!

What limits your tool to compiler/build tools, can it be used for any arbitrary process?

I am extremely interested in this.

I am stuck in an environment with CMake, GCC and Unix Make (no clang, no ninja) and getting detailed information about WHY the build is taking so long is nearly impossible.

It's also a bit of a messy build with steps like copying a bunch of files from the source into the build folder. Multiple languages (C, C++, Fortran, Python), custom cmake steps, etc.

If this tool can handle that kind of mess, I'll be very interested to see what I can learn.

This is fabulous!!

Is there a version available for MacOS today?? I'd love to give it a whirl... For Rust, C++ / Swift and other stuff.

Thanks!

The real solution is to eliminate build systems where you have to define your own targets.

Developers always get it wrong and do it badly.

Nice, I’ve been looking for something like this for a while.

I’ve noticed on my huge catkin cmake project that cmake is checking the existence of the same files hundreds of times too. Is there anything that can hook into fork() and provide a cached value after the first invocation?

What about OSes that dont use fork()?

Nice! Leaving a comment to easily find this later, dont have anything to add except this looks cool

> It also has 6 seconds of inactivity before starting any useful work. For comparison, ninja takes 0.4 seconds to start compiling the 2,468,083 line llvm project. Ninja is not a 100% fair comparison to other tools, because it benefits from some “baked in” build logic by the tool that created the ninja file, but I think it’s a reasonable “speed of light” performance benchmark for build systems.

This is an important observation that is often overlooked. What’s more, the changes to the information on which this “baked in” build logic is based is not tracked very precisely.

How close can we get to this “speed of light” without such “baking in”? I ran a little benchmark (not 100% accurate for various reasons but good enough as a general indication) which builds the same project (Xerces-C++) both with ninja as configured by CMake and with build2, which doesn’t require a separate step and does configuration management as part of the build (and with precise change tracking). Ninja builds this project from scratch in 3.23s while build2 builds it in 3.54s. If we omit some of the steps done by CMake (like generating config.h) by not cleaning the corresponding files, then the time goes down to 3.28s. For reference, the CMake step takes 4.83s. So a fully from-scratch CMake+ninja build actually takes 8s, which is what you would normally pay if you were using this project as a dependency.

This is great. I was skeptical from the title but the implementation is very clever. This could be a super super useful tool for the industry.

That's interesting.