From the description alone, it’s not clear to me how early cutoff works in practice, when mtimes instead of content hashes are used: let’s say the hash for the compilation of some .o file changed, so we re-run the action, and get the same .o file! But now the .o file has a newer mtime, so it reruns also all the steps downstream and so on.
My understanding from the post and looking at the linked restat command in the manual, is that Ninja depends on the underlying compiler not modifying the output file when it won’t change, otherwise Ninja will only be able to see new mtimes. I might be incorrect though.
Is the world being focused on value added of new things meaning that maintenance of old things is not researched as much? How many frameworks for the fast creation of a blag or a todo list exist when much of what I’ve done over my career is maintenance of large successful systems.
How much better would security, reliability, and maintainability be if more folks focused on this aspect of the craft?
What exactly are you responding to? This is the creator of a software system exploring a new design. The original is still maintained and quite stable. And needless to say, it has nothing to do with blogs or todo lists; it’s an iteration on a solution to an incredibly complex problem.
Backwards compatible (it acts as a drop-in replacement for Ninja)
Exploring a very different point in the design space, to the point that there would be very little shared code between the two implementations if they were in the same program.
The design of n2 looks really nice and addresses a lot of the problems with Ninja. In particular, the model should be trivial to extend to cloud-based caching and builds. Given the author’s track record, I have a pretty high confidence that it will have a massive impact.
I use Ninja a lot and it probably saves me at least a minute of waiting time in total each day that I use it. Even using it for 100 days a year, over the 15 years that I’ve been using it, that’s 25 hours of my productivity that Ninja has given me (probably more). Scaled up across all of the users of Ninja, that’s a huge win.
The FreeBSD package builders switched a while ago to using Ninja for all CMake-based projects, which shaved a pretty noticeable amount off the total time to build a complete package set.
If the author wrote wasted the rest of his life doing nothing productive or writing ‘frameworks for fast creation of a blag or a todo list’, he’d still probably have a more positive impact on the industry than most of the rest of us.
From the description alone, it’s not clear to me how early cutoff works in practice, when mtimes instead of content hashes are used: let’s say the hash for the compilation of some .o file changed, so we re-run the action, and get the same .o file! But now the .o file has a newer mtime, so it reruns also all the steps downstream and so on.
My understanding from the post and looking at the linked
restatcommand in the manual, is that Ninja depends on the underlying compiler not modifying the output file when it won’t change, otherwise Ninja will only be able to see new mtimes. I might be incorrect though.I guess even if the compiler doesn’t support it, a wrapper that hashes the file twice is cheap compared to running the compiler itself.
Is the world being focused on value added of new things meaning that maintenance of old things is not researched as much? How many frameworks for the fast creation of a blag or a todo list exist when much of what I’ve done over my career is maintenance of large successful systems.
How much better would security, reliability, and maintainability be if more folks focused on this aspect of the craft?
What exactly are you responding to? This is the creator of a software system exploring a new design. The original is still maintained and quite stable. And needless to say, it has nothing to do with blogs or todo lists; it’s an iteration on a solution to an incredibly complex problem.
And, in particular, it is a new design that is:
The design of n2 looks really nice and addresses a lot of the problems with Ninja. In particular, the model should be trivial to extend to cloud-based caching and builds. Given the author’s track record, I have a pretty high confidence that it will have a massive impact.
I use Ninja a lot and it probably saves me at least a minute of waiting time in total each day that I use it. Even using it for 100 days a year, over the 15 years that I’ve been using it, that’s 25 hours of my productivity that Ninja has given me (probably more). Scaled up across all of the users of Ninja, that’s a huge win.
The FreeBSD package builders switched a while ago to using Ninja for all CMake-based projects, which shaved a pretty noticeable amount off the total time to build a complete package set.
If the author wrote wasted the rest of his life doing nothing productive or writing ‘frameworks for fast creation of a blag or a todo list’, he’d still probably have a more positive impact on the industry than most of the rest of us.