I get immediate success with the approach as far as building is concerned; I’ve also replaced raylib back with master which just worked. Nice.
Regarding zls, I’ve not been as successful.
If anybody has a guide “from 0 to working zls even with this raylib setup in nvim using lazy using a zvm managed zig & zls” I’d appreciate it.
I could not get Zls working on Windows using this method (package manager).
But I did manage to get it working with raylib as a submodule. Example here GitHub - everystone/raylib-zig-template
Updated zigraylib example to a zig 0.12.0 compatible commit.
Via: zig fetch --save=raylib https://github.com/raysan5/raylib/archive/b03c8ba945a06ed1ec3d6ed7c3185e1264909323.tar.gz
Commit: https://github.com/raysan5/raylib/tree/b03c8ba945a06ed1ec3d6ed7c3185e1264909323
Tested with zig version 0.12.0
Zls tagged release 0.12.0
Updating zls:
git pull
git checkout tags/0.12.0 -b 0.12.0
zig build -Doptimize=ReleaseSafe
Tested on linux, zls is working.
Now that zls has a 0.12.0 release everything seems to work fine.
@msw and @Eirik if you want, you could try again with these versions?
I logged what I did in case it would prove useful to communicate what’s going wrong if there’s something wrong or what mistake(s) I might’ve made – turns out this now is a log of a successful test’s “debug output”:
mkdir zls-test
## NVIM config
# Start with a fresh nvim config
# I am a newbie to nvim (coming from pluginless vim)
# so I use what others think is a "modern" editing experience
git clone https://github.com/LazyVim/starter ./zls-test/config/nvim
rm -Rf zls-test/config/nvim/.git
# let lazyvim starter kit plugin cascade setup & install..
env XDG_CONFIG_HOME=${HOME}/zls-test/config\
XDG_STATE_HOME=${HOME}/zls-test/state\
XDG_DATA_HOME=${HOME}/zls-test/data\
nvim
## ZLS
# get zls as per instructions;
# install zls by copying the binary to zls-test/zls
## RAYLIB example
cd zls-test
git clone https://github.com/SimonLSchlee/zigraylib.git zrl
cd zrl
zig build run ;# ok - works
## Now for the hard (for me) part. Configure to use zls.
# disable mason:
<<EOF cat > ~/zls-test/config/nvim/lua/plugins/no-mason.lua
return {
-- disable mason
{ "williamboman/mason.nvim", enabled = false },
}
EOF
# configure via nvim-lspconfig
<<EOF cat > ~/zls-test/config/nvim/lua/plugins/zls-lspconfig.lua
return {
{
"neovim/nvim-lspconfig",
opts = {
servers = {
zls = {
cmd = {
"/home/phaeton/zls-test/zls",
},
settings = {
zls = {
zig_exe_path = "/home/phaeton/.zvm/bin/zig",
},
},
},
},
},
},
}
EOF
## fine, let's try this?
env XDG_CONFIG_HOME=${HOME}/zls-test/config\
XDG_STATE_HOME=${HOME}/zls-test/state\
XDG_DATA_HOME=${HOME}/zls-test/data\
nvim src/main.zig
# check lsp attachment via :LspInfo, outputs attached client:
# Client: zls (id: 1, bufnr: [1])
# filetypes: zig, zir
# autostart: true
# root directory: /home/phaeton/zls-test/zrl
# cmd: /home/phaeton/zls-test/zls
#
# toying around: yes, indeed it works!
So, it seems to me I can make this work from scratch.
Thanks!
(tested with zvm-installed zig 0.12.0, manually installed zls as per above, no ${XDG_CONFIG_HOME}/zls.json etc., all config present above in log)
A post was split to a new topic: How to use raylib as a dependency of a dependency?
Thanks to nat3Github Adding raygui · Issue #5 · SimonLSchlee/zigraylib · GitHub
I took another look at raylib’s build.zig and raygui, and realized that it can be integrated more easily than I thought (or than it could in the past / not quite sure which) into an example.
Checkout the raygui branch if you want to use raylib + raygui.
This thread saved me a lot of time and headache. Excellent. It just works for Zig 0.13.0
Hello. Thanks for this. I was going to use it as starter. but I am facing this issue, do by any chance have any idea what it is
zigraylib main* 11s via ❄️ impure (nix-shell-env)
❯ zig build
install
└─ install zigraylib
└─ zig build-exe zigraylib Debug native failure
error: warning(link): unexpected LLD stderr:
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/ylzpk54f82kc888pr4325ynshk48la6i-libglvnd-1.7.0/lib/libGLX.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/wfrgia7qj3ijrxl9irsqvjfz20qqx5fm-libX11-1.8.12/lib/libX11.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/f90pwkhqw3ddp8a006l536ckxnx8rlax-libXcursor-1.2.3/lib/libXcursor.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/inh6jc1w3fl95j7crcp5vyih7macq4py-libXext-1.3.6/lib/libXext.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/k5lslg4k7jd105wmiahvfymwad14r3zr-libXfixes-6.0.1/lib/libXfixes.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/yn7wjwgjlk7y53l73fljfvvzyw6hn624-libXi-1.8.2/lib/libXi.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/344qwdpsgflcv3j2l2nn30r7p9816kpg-libXinerama-1.1.5/lib/libXinerama.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/m5mvqvx6fyrsayz2rnab0yy64885fz6x-libXrandr-1.5.4/lib/libXrandr.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/l3138hd3gy3i0gcpw9xs41h6a8hf0m00-libXrender-0.9.12/lib/libXrender.so' is neither ET_REL nor LLVM bitcode
ld.lld: warning: /home/aldrich/workspace/zigspace/lrn/zigraylib/.zig-cache/o/d485c29df9b85fd3582590b5e2bf9df7/libraylib.a: archive member '/nix/store/wfrgia7qj3ijrxl9irsqvjfz20qqx5fm-libX11-1.8.12/lib/libX11.so' is neither ET_REL nor LLVM bitcode
I also get these warnings, but as far as I can tell it works anyway.
I am also not sure why these warnings are generated and if they could be avoided, that is the trouble with warnings you don’t know whether you should consider them a hard error or just something to think about.
So far I didn’t have the time to dig in and figure out more about it.
would you prefer to have them be an error? I’m also seeing them, and I’m also not investigating. Having them be an error would’ve at least made me bisect which zig version introduced these (< 14.0; was it an LLVM update?).
Hi, welcome to the forum, I think those warnings, are a by product of the fact that raylib.a is an archive, that statically links those libraries, symbol, so when the linker sees an archive it expects symbols like .o are .a with the et_rel to relocate, but because those are .so aka shared object, the linker can’t relocate them, therefore it’s complaining. I don’t think it’s a big deal, and I’m pretty sure that warning was just silent before, but was still there. That’s my best guess
A post was split to a new topic: How to build raylib project using nix flake?
zig-0.14.0 and zig-0.15.2-Dtarget=wasm32-emscriptenI also wanted to add a tag for zig-0.16.0 but that version has a problem with emscripten builds, so I will likely skip that version and create the next tag for 0.17.0.
How does this project and GitHub - raylib-zig/raylib-zig: Manually tweaked, auto-generated raylib bindings for zig. https://github.com/raysan5/raylib · GitHub compare against each other?
I am probably not the most qualified to answer this question, so you probably also should ask people who really have used raylib-zig in depth, I haven’t.
This is a minimal example of directly using the translated raylib c api with zig.
Benefits:
Drawbacks:
raylib-zig is more like a full binding.
Benefits:
Drawbacks:
Overall it mostly depends on whether you want to use a full binding or not and whether you like the api that the binding gives you.
I have no usage experience with the binding, so you will have to try it yourself and make your own decisions.
I also have begun to work on my own raylib wrapper (but I am not sure yet when I will get that out or even if I will continue working on it), where I intend to make some of my own opinionated changes. Because I am working on my own wrapper, that also keeps me from wanting to use another binding.
Having tried both a bit (though more of raylib-zig admittedly), this is generally spot on imo.
I’ve had no issues at all with raylib-zig and I really enjoy the idiomatic types/naming, but it does add a larger dependency as you’ve noted.
One thing I’m curious about is WASM/Emscripten support. raylib-zig relies on emsdk. Have you tried compiling just using Zig’s Emscripten target for a Raylib project? I’m not very well versed in WASM, so I apologize if that just doesn’t make sense.
The build.zig.zon that is in the raylib repository does too.
No, all the raylib projects I know of use emsdk one way or another, some use it as a dependency others install it manually.
I don’t think Zig tries to replace emscripten, so far I thought of wasm32-emscripten as build a wasm32 thingy that can then be handed off to emscripten to produce the final result and that is also how all the build scripts I have seen work.
So I am not aware of anyone using wasm32-emscripten as target without using the emsdk.
But there are some good examples of people using wasm32-freestanding directly and thus not needing emsdk.
That makes sense. Appreciate the clarification.