Ninja religions following of treating timestamps (mtime) as 'modified' marker makes it useless with Git and large projects.

You switched some branches back and forward? Enjoy your 20 minutes rebuild.

* https://github.com/ninja-build/ninja/issues/1459

▲

jhasse a day ago | parent | next [-]

Good news, I've been working an adding file content hashing to Ninja: https://github.com/ninja-build/ninja/pull/2735

That will fix the "switch branches back and forward" case :)

▲

dezgeg 2 days ago | parent | prev | next [-]

I believe the same author has made a ninja successor (n2) that uses hashes instead. Haven't tried personally but hopefully get around to try that in the near future

▲

menaerus 2 days ago | parent | prev [-]

I have never observed that issue, and I have been using it to build MMLoC repositories. Perhaps the reason being is that I always use it coupled with ccache. Have you tried that?

▲

throwway120385 2 days ago | parent [-]

ccache is a workaround for the mtime problem. You can either hash with ccache or hash directly in the build system, but either way there's no substitute for hashing something. Ccache is hashing the input to the build, but there may be elements of the build that lie outside of ccache's awareness that having a hash-aware build system would take care of. Partial rebuilds devolve to a cache invalidation problem pretty quickly either way.

	▲	menaerus 2 days ago \| parent [-]
		I'm obviously aware that ccache solves the mtime problem which is why I find disingenious to say that switching branches with ninja is "totally unusable". Therefore my question. Hash-aware build systems like bazel, if that's what you're imputing, are a nightmare to work with and come with their own set of problems which make it much less appealing to work with than (some) limitations found in cmake+ninja