Feature request(s): Improvements to configuration for alternative build systems

[alexrp]

In zig-msbuild-sdk, I would like to generate a zls.json as part of the build so that users can use ZLS in e.g. VS Code and have things Just Work. There are some limitations in ZLS that prevent this at the moment:

1. ZLS only searches for zls.json in configuration folders. I need a way to point it to the zls.json that I generate inside the project folder. Usually, this will go into obj/<configuration>/<platform>/zls.json (e.g. obj/Debug/linux-x64/zls.json).
2. Configuration doesn't seem to be hierarchical. This means that the user wouldn't be able to have a zls.json at a higher level which modifies behavioral options like enable_snippets, operator_completions, etc.
3. There seems to be no way to communicate Zig packages to ZLS without using zig build in some fashion. This information is readily available in my SDK - I just need a way to pass it to ZLS. A packages list in zls.json might be a reasonable solution.

[SuperAuguste]

This is quite an interesting usecase for an alternate method of feeding package to zls, saw some buzz about similar ideas surrounding gyro and zigmod integration with zls. Is this still something you'd be interested in?

On the configuration front, what's a solution you would propose? Our configs are a lot more flexible now by the way :)

[alexrp]

This is quite an interesting usecase for an alternate method of feeding package to zls, saw some buzz about similar ideas surrounding gyro and zigmod integration with zls. Is this still something you'd be interested in?

I am not super familiar with gyro and zigmod, but from a cursory glance, it seems that they both to some degree integrate with Zig's build system. In my case, I don't use the Zig build system at all, so it would (I imagine?) require a completely separate mechanism to tell ZLS about the list of packages. It's definitely still relevant for ZLS integration with my project and would address point 3.

On the configuration front, what's a solution you would propose? Our configs are a lot more flexible now by the way :)

First, I would suggest just copying wholesale the hierarchical nature of clangd's configuration system. This would address point 2.

---

Point 1 is going to be a bit trickier. Since the zls.json that my SDK would generate is not meant to be checked into source control, it would be highly preferable if I could place it into the obj folder. The tricky part is communicating to ZLS that it should use the zls.json from there.

One solution I could think of would be a configuration 'include' mechanism. So, in the project directory, the user might have a zls.json looking something like this:

{
    // ...
    "include": "obj/Debug/linux-x64/zls.json"
}

Incidentally, using a .clangd file with my SDK looks very similar:

# Point to the directory containing the compile_commands.json file generated by my SDK.
CompileFlags:
    CompilationDatabase: obj/Debug/win-x64

This project-level zls.json would be added to .gitignore, much like .clangd files. Finally, my SDK would be in charge of generating obj/<configuration>/<platform>/zls.json with all necessary information about where to find the Zig compiler, standard library, packages, etc.