search

SolaWing / xcode-build-server

a build server protocol implementation for integrate xcode with sourcekit-lsp
MIT License
283 stars 16 forks source link

Detecting changes in other files #52

Open wojciech-kulik opened 1 month ago

wojciech-kulik commented 1 month ago

This is most likely connected with #43.

Besides the problem with new files, there is also one more annoying. Whenever I update some other file by for example adding a new parameter to a function, these changes are not visible for LSP until I rebuild the project and restart LSP.

Actually, LSP restart is not needed if I alternatively just update buffers with errors. However, diagnostics won't disappear automatically until some changes are made.

I wonder how Xcode handles it. Does it recompile just a single file? Because Xcode is able to almost instantly notice new params.

Running a build in a background for every change in a buffer, doesn't seem reasonable, so probably it is more difficult case than #43.

SolaWing commented 1 month ago

xcode does do background index. even more, if you open same file with xcode and keep it in background, you will notice your symbols is updated automatically too. xcode may only run only single file command, not the entire build and precondition handle so it's fast to only update index. @fireplusteam seems may familiar more. I may try to rerun the single file build command to see if it works..

wojciech-kulik commented 1 month ago

Would be great to try. If it works, it would significantly improve the work :)

fireplusteam commented 1 month ago

@SolaWing , on a file change xCode starts a build of a file with regards to dependencies of this file. If it requires some modules rebuilt first, it would rebuild it first, but yes in the end the whole project has to be updated to make full symbols work. It's faster because Xcode doesn't release XCBuildService each time after rebuild, so it can cache any data to speed up the response.

@wojciech-kulik actually using a proxy you can tell XCBBuildService to do the same. You just need to send a request which is in fact is JSON converted to binary format. Saying you can set some environmental variables and start the request with xcodebuild but change the JSON on a fly and imitate the indexing feature. Anyway for cross-modules you need to rebuild to update frameworks. So because of that, I don't use that feature but directly start to rebuild a project in two cases:

  1. The project file or some of the subproject files are changed
  2. A user made a change in a module and switched to another one in your editor

If you made a change in a single module, indexing is working fine within that module but not for others, that's why manipulating with flags for a newly added file is not useful because we have a lot of use cases that can be resolved with the full rebuild as only XCBBuildService knows how to resolve them.

There are several ways to decrease response time you can: a) async parser of logs b) keep xcbuildservice process and don't restart it each time when you trigger a build with xcodebuild. It does use some caching internally to speed up the time response but it's released each time after a manual build. Xcode communicates with it like with a service and keeps it until Xcode is closed. (But that solution requires a proxy and private implementation of it)