when i zig build my top-level project, i receive an error from this particular step:
C:\Users\biosb\AppData\Local\zig\p\1220bd3c80953a714035a595b0e0bcebe449dae0af8add7d25aafb46f0f50085c007\src\main.zig:4:29: error: no module named 'exe_options' available within module root
const exe_options = @import("exe_options");
the "exe_options" module is in fact created within the build.zig found in the my-zls project… it is NOT part of my top-level build.zig…
said another way, how do i build my-zls using its associated build.zig under the control of my top-level build.zig???
Unless your goal is not to create your own LSP, but rather repackage ZLS, in which case nevermind :^)
If your goal is to expose the ZLS executable from your package, you can directly get a reference to it from the ZLS dependency.
Something along the lines of b.dependency("zls", .{}).artifact("zls").
If instead you want to wrap it into an executable of your own, then you will need to basically copy the whole definition of the ZLS executable in their build.zig.
If you can share more about your use case we can be more helpful.
i’ve forked ZLS at the point at which it (first) supported zig 0.13.0, and have made some very minor additions to semantic_tokens.zig… i have a corresponding fork of vscode-zig, which adds some distinct highlighting to these new token types…
for now, i’m looking to simply deliver my ZLS executable (plus my VS Code .vsix extension) with my next release of Zig•EM… given that my user is already doing a zig build on their host computer, why not simply produce the ZLS executable at this time as well???
it sounds like what i “really” want to have happen is to execute zig build as a sub-command on my dependent ZLS repo??? presumably i could pass an option to this instantiation of zig build which would direct the compiled executable to be placed (say) in a tools/ folder at the root of my top-level project… [[ worse case, i could simply add a step to explicitly copy the file ]]
this is quite different from my other zig-based dependencies (eg., zig-cli) which will be imported by my own zig-based app (and are effectively compiled as part of it)…
in summary, i CAN orchestrate a zig build of my ZLS as a sub-command… is this my “least worst” but simplest path forward???
In this case you want to go with my suggestion from before: the build.zig script inside of your ZLS dependency already exposes a way of fetching the executable without needing to do anything complicated.
In your build.zig obtain the zls artifact from your dependency and install it: