evmar
n2 re-runs generator on first build
- Grab latest LLVM
- Install n2 as
ninjain the PATH -
cmake -GNinja ../llvm -
ninja-> cmake being re-built
This might be something in the LLVM CMake scripts of course, but I wanted to report it anyway since using it for LLVM would give some good benefits.
I retitled this about the larger issue, which is that n2 doesn't recognize when your build files have been generated outside of n2. I have been thinking about this issue and I'm still not quite sure what to do about it.
BTW the gn build of llvm (https://llvm.org/devmtg/2018-10/slides/Weber-FunnerLLVMDevelopment.pdf) generates so quickly you don't notice this happening. :)
My current best thought is to have some sort of adopt subcommand where you tell n2 "trust me, file foo and all its dependencies are up to date relative to its inputs", and then somehow automatically adopt generated build files. But I'm not sure how to tell apart the case where you ran CMake manually vs the case where you've e.g. directly
edited a generated build file and we ought to rebuild it.
How does ninja do this currently? Guessing it keeps track of the files another way? I seem to remember that CMake automatically calls ninja after each configure to clean up the dep tree or something. Maybe n2 could hijack those tools in an ugly way.
CMake calls ninja -t restat to fix this, see https://github.com/ninja-build/ninja/issues/1376
I am kinda unhappy with my solution here, I am thinking it over still so I am gonna leave this bug open.
Notes to self, there are two broad situations we care about:
- User generates build files the first time, invokes n2.
- User invokes ninja generator manually atop existing build.
The -t restat thing solves both of these by having CMake directly call ninja to inform it that it did something, but it requires we install n2 as the ninja binary found by CMake.
But we could solve case #1, which is the only case this bug was initially filed about, by just saying "if there was no .n2_db file, mark build.ninja as up to date immediately", which requires much less user intervention. And case 2 is possibly a relatively rare user scenario (?)
I just retested this today and n2 re-runs CMake everytime on windows. I can check on it if you think it should work, then it might be another Windows specific issue.
@evmar ping on this again, with the other issues handled now, this is the one that's blocking me from using n2 daily. It re-runs CMake on every invocation. Any tips on how to debug that?
Hi! Yeah it seems like it worked on the initial test, I will use n2 as my default ninja for a while and let you know if I ever encounter it again!
I am back to thinking about this again because Meson also triggers this.
Relevant code only invokes -t restat if there is a .ninja_log file in the build dir, which is to say Ninja was already run once.
In n2's case it rebuilds in any case where it doesn't know the provenance of generated files, so that is not enough. And the current thing where to make CMake work we require you to install n2 as your ninja binary is a seriously gross hack, so it would be nice to have a more principled fix here.
The original meson implementation of running the restat tool checked for file existence first. I'm not fully certain why. It looks like ninja -t restat is a no-op if the log file doesn't exist, so it should be safe to unconditionally run it?
