Builder allows to compile an application using different SDK, from the operating system and from a installed flatpak one.
For GVls found it requires to know the path to vapi directory in current SDK, so it can find packages like
libvala-?? in use to provide correct diagnostics.
Navigating around the
Ide API, found no way to execute:
valac --api-version in order to construct
.pc file to get paths from
pkg-config --variable datadir libvala-0.?? in order to construct the path to the generic VAPIDIR and current vala version VAPIDIR using
pkg-config --variable vapidir libvala-0.??
Above will help to fix missing package found in current Builder GVls plugin, because currently it doesn’t provide that configuration to the LSP diagnostics provider.
This is why I think the right answer for LSPs it to actually create SDK extensions where the LSP lives. Then you always know /app/lib/girepository-1.0 and /usr/lib/girepository-1.0 for anything Flatpak related. Then the plugin finds the right LSP within the build environment instead of being shipped with Builder.
But if you must, you can always create a a new subprocess using
pkg-config --variable=vapidir vapigen from the configuration’s
Maybe pointing out where to find documentation about how to create SDK extensions could help.
This issue is about the Plugin not the LSP, because is Builder the one who knows the build environment, so is the one who should notify LSP about any change.
By the way, are there any way to know any runtime change? so LSP is notified about new configurations?
As for SDK extension documentation, you’ll have to do your research.
LSPs are all different in this respect, which is why it is left to the plugin which is bridging the configuration to update the LSP daemon in a way it knows.
You can connect to the notify signal for configuration updates.
cfgmgr = Ide.ConfigManager.from_context(context)
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.