I added n2 support to my `pcons` tool, just FYI

[garyo]

This is just a thank-you, not an issue, so feel free to close any time, but I wanted to let you know I implemented n2 support in my https://github.com/DarkStarSystems/pcons tool, for users who want hash-based rebuilds. It was super easy since you read ninja files. Thanks for doing this!

[evmar]

Hey thanks for telling me, your project looks neat!

One idea I have had in this space is that the steps you need to run during your 'configure' phase are themselves kind of build-system shaped, in that they involve computing something slow that you want to cache in subsequent runs. I have wondered if you could express even these configure steps as an initial build graph for a tool like n2, which would let it execute the configure steps themselves in parallel, and maybe even know when to rereun them if some input circumstances change? Anyway, this isn't an area I know too much about, just an idea to share. In particular I think it might mean you end up regenerating your build files multiple times during your initial build, which is maybe clunky to support with ninja; I forget how it decides whether it needs to rerun, like whether it runs in a loop or not.

Also, I skimmed DarkStarSystems/pcons@6ae7359 and wanted to correct you: n2 doesn't do content hashing of file contents. It (confusingly!) does use content hashing for dirty checking. I talked about this distinction a bit in the original blog post here: https://neugierig.org/software/blog/2022/03/n2.html

[garyo]

Thanks, I updated my docs to be more accurate. I was a long-time co-maintainer of SCons, which does full content hashing of everything, so I know that there's a subset of users who want that. They can use ccache though; I expect the combination of n2 + ccache should lead to reliable and fast builds.

SCons also does the configure-as-sub-build idea you mentioned; it always felt bolted on though, and was never really flexible enough. What if you make decisions based on results of a test compilation? Or maybe you write some results to a header file, and others just set build variables. I feel like the config part has to be Turing-complete. On the other side though, parallelizing config checks would be a big win for larger projects. It's worth some more thought. pcons does have a simple config cache for its test results though. Nothing fancy.