Open randomascii opened 6 years ago
BTW, a typical gn gen command I might use would look like this:
gn gen --ide=vs --filters=//base --no-deps out\debug_component
This creates a minimal solution file that lets Intellisense work for types in base. This solution file loads quite quickly so the cost of updating it ends up dominated by the VsChromium reload time.
It is common for the content of the .sln file to change, or does this happen mainly because "gn gen" re-generates the same file without checking the contents of previous one? (I am wondering, because it would even be better to have "gn gen" be smarter and not touch files that don't change).
I'm not sure what counts as "normal". gn gen is smart enough to not update the .sln file or .vcxproj files if nothing has changed. If just .vcxproj file contents have changed then I don't know if it is similarly smart.
In this particular case I was altering my --filters arguments to add more projects so the .sln file was necessarily changing. The same issue could happen if a user is switching between .sln files that both cover the same project directory - I've done that a few times I'm sure. I notice this the most on my home laptop which is a bit slower to reload the index.
Ah ok, that makes sense.
This is address in release 0.9.33: https://github.com/chromium/vs-chromium/releases/tag/v0.9.33
Awesome!
When a solution file changes (perhaps because it is pulled from version control, perhaps because a new version is created by gn gen --ide=vs...) then the old solution is closed and then the new one reloaded. There is a brief window when there are no tracked files loaded and VsChromium is very quick to discard its index, only to have to recreated it a fraction of a second later.
It would be nice if VsChromium could handle this without having to rescan. One possible way would be to have a brief delay before discarding the index - half a second? A few seconds? I don't know.