I'm not sure what you would propose we do here? 

In theory everything in the build should declare the dependencies it has, but if there's something missing I don't know how GN would know that?

Note that the bots explicitly run GN every time and won't necessarily have a problem here.

For example, build.gn could have a dependency on .git/logs/HEAD.

That would cause GN to re-run on every local commit, which could be result in unnecessary invocations in some cases (when nothing has changed) and miss things in others (e.g., if you made uncommitted changes that would affect the build and were otherwise unreferenced in the build graph).

Missing local uncommitted changes is ok I think. about:version can miss those, clang rolls usually aren't in that state very long, and I can't think of anything else that would dramatically affect the build.

Rerunning gn on local commits would be annoying though. Maybe gclient could write some well-known file on syncs that gn could depend on. I guess build/util/LASTCHANGE is such a file already -- maybe build.gn could just depend on that?

(Also, unrelatedly, we should get rid of LASTCHANGE.blink, now that I look at lastchange in DEPS)

Maybe gclient sync could just touch src/.gn (or something else)?

I'm guessing that brettw@ would argue that if something changes in the build and GN doesn't detect it, the build is just broken, and we shouldn't be trying to work around it in this way.

I can see an argument that it'll be too hard to be 100% correct and it's not that painful to take a few second hit during runhooks to be safe, but I'm not quite convinced of that yet; I'd like to see us hit a few more bugs before we gave up completely.

I don't think doing something about this issue needs to block the GN migration (particularly since the bots won't be affected by this), so I'm going to drop that label, but add the GN label instead).

Well, then for about:version Brett would argue to depend on .git/logs/HEAD, since that's the input for the LASTCHANGE generator I suppose. It's a tricky problem with different tradeoffs though, and I think running your metabuild system after syncs is actually a pretty good approach (I wrote http://neugierig.org/software/blog/2014/11/binary-revisions.html about this a while ago.)

(From a more pragmatic point of view, the thing I care most about is that gn-using devs don't run into pch version mismatch errors after clang rolls. If I can say "also make build.ninja depend on third_party/llvm-build/Release+Asserts/bin/clang", that'd fix that. But rerunning gn after syncs also fixes that, and fixes other similar issues -- it seems like a better fix to me.)

I'll punt this to brettw@ for now.

> For example, build.gn could have a dependency on .git/logs/HEAD.

For Clang's purposes, could we just make build/config/compiler/BUILD.gn depend on tools/clang/scripts/update.py? There is a real dependency there, as the gn file needs to exec_script the py file to configure the build.

I'd be happy to send a patch but I'm not sure how to express such a dependency in gn. Any pointers?

Anything loaded with exec_script (or listed on the additional input dependencies to that call) will already cause GN to be re-run the next time you build.

Hm, then clang updates should already work fine.

But sometimes they don't (https://bugs.chromium.org/p/chromium/issues/detail?id=608105#c4). I guess that's due to something else then and this is bug here is WontFix (or Fixed).

I can confirm that update.py is in out/gn/build.ninja.d

Let's close this as "reporter doesn't know what they're talking about"