I looked into landmines, and they appear to be a quite blunt instrument for forcing clobbers of the entire fleet. They don't appear to be used for "checkout is in state x, therefore clobber and rebuild". When I think of it, that's ninja's job. You don't clobber a checkout after just changing one .cc file for instance, but ninja figures out what to rebuild.

All right, so if you change the ndk variable, the following copt will change: "-D__ANDROID_API__=$compile_api_level",

and I believe it will change for every cc file. I would expect that to lead to full rebuild of everything, but it appears it doesn't?

... And the problem is that the define doesn't change if I change the variable; I changed it from 16 to 18 and I still get 

-D__ANDROID_API__=16

So the whole problem is to get that copt to re-generate.

Doing this works just fine though:

gn gen --args='android32_ndk_api_level=19 ...' out/Android

so at least a clobber isn't necessary, just a gn gen. The thing that doesn't work is changing the variable in our .gn and then running ninja.

I agree that a 'gn gen' is probably enough. The problem is not only the __ANDROID_API__ macro but the value of some paths in out/<...>/toolchain.ninja.

The version of the NDK API is part of some paths, e.g.:
-Wl,--no-whole-archive ../../third_party/android_ndk/platforms/android-16

If they aren't updated, we can get linker errors.

In this case the problem is that libaaudio.so is not present in ../../third_party/android_ndk/platforms/android-16/arch-arm/usr/lib/. We want to raise the API level to 26.

Brett, Dirk: is there any way to trigger a gn re-gen if our .gn changes? Can we add it somehow to build.ninja.d?

Anyway: it also works fine to just change the variable and run a gn gen. This won't be a problem, therefore, on the bots since they always run an explicit gn gen before invoking ninja.

I played around with adding .gn to data, but I don't know where a good place would be to add it. Anyway, this isn't much of a problem. I'm fine with just adding a comment to the variables in our .gn and calling it a day.

Yes, if bots are fine (and it looks like they are... At least now they are not broken because of the linker error) I think we can live with a comment into the .gn file.

To wrap up this bug:

* Trybots will be fine (I don't know why I thought they were failing, I probably overthought the problem). 
* Local checkouts will have to run a 'gn args out/<name_of_the_build>', keep the args as is and just close the editor. This will re-generate all the ninja files and everything will work.

Thanks Patrik for this.