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.

[Techatrix]

Perhaps a bit late but is this still an issue or did anything change since then?

I'd like to avoid the additional complexity from a hierarchical configuration system that has been suggested here. But the use case of supporting alternative build systems is reasonable to me.

Ultimately, what you need is a way to provide information about the Zig build system (modules, import tables, compilation units) to ZLS without a build.zig right?

ZLS has a related zls.build.json config file that can be placed next to a build.zig to set some options that are specific to a build file. This system is currently very limited and still relies on the presence of a build.zig but I could foresee this system being expanded to handle alternative build system and possibly a hierarchical structure as opposed to zls.json.

To figure out the best way forward, I like to understand vezel-dev/zig-sdk better to figure out what exactly it needs. Is there perhaps some kind of example project I could look at?