OK, so I've started to get things working on my windows machine.
I have the following versions of stuff
Now running cargo run repl
I get
Compiling num-traits v0.2.14
Compiling ahash v0.7.4
Compiling im-rc v14.3.0
error: failed to run custom build command for `roc_builtins v0.1.0 (C:\Users\Matthias\Documents\GitHub\roc\compiler\builtins)`
Caused by:
process didn't exit successfully: `C:\Users\Matthias\Documents\GitHub\roc\target\debug\build\roc_builtins-7593273b6bf0ccc6\build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-changed=build.rs
cargo:rustc-env=BUILTINS_O=C:\Users\Matthias\Documents\GitHub\roc\target\debug\build\roc_builtins-fc62ed947dc1042e\out\builtins.o
Compiling zig object to: \\?\C:\Users\Matthias\Documents\GitHub\roc\compiler\builtins\bitcode\builtins-64bit.o
--- stderr
thread 'main' panicked at 'zig failed: error: BadPathName
', compiler\builtins\build.rs:115:17
stack backtrace:
0: std::panicking::begin_panic_handler
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panicking.rs:515
1: std::panicking::begin_panic_fmt
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\/library\std\src\panicking.rs:457
2: build_script_build::run_command<str*,[str; 3]*,std::path::PathBuf*>
at .\build.rs:115
3: build_script_build::main
at .\build.rs:51
4: core::ops::function::FnOnce::call_once<fn(),tuple<>>
at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633\library\core\src\ops\function.rs:227
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
error: build failed
:thinking:
Interesting. I bet the issue is coming from fs::canonicalize(Path::new(".")).unwrap()
Which on your windows machine is generating a path that starts with \\?\C:
. I think that path maybe throwing off zig even if rust seems capable to set it as the current directory path. That is at least my guess
From the docs on the function:
On Windows, this converts the path to use extended length path syntax, which allows your program to use longer path names, but means you can only join backslash-delimited paths to it, and it may be incompatible with other applications (if passed to the application on the command-line, or written to a file another application may read).
oh, we should update those docs - the compiler currently doesn't work on Windows :sweat_smile:
would e.g. the repl work?
that will change once the surgical linking project is done though!
Ah, ok! No worries, I can set it up on my other machine :D
the repl used to with the llvm jit execution engine, but now it would need to know about dlls to work
I suppose getting the repl to work isn't blocked on surgical linking :thinking:
I was going to take another attempt at this tonight on my Ubuntu machine. Safe to assume linux is fine for the compiler?
Otherwise I can do my mac. And if that doesn't work, there's always my old TI-83 calculator
however I may be out of devices after that :thinking:
linux is fine
as is mac, mostly
calculator though, not sure
but apparently doom runs on landline phones these days so who knows
I noticed some flaky gen tests on Mac recently, but otherwise everything seems fine
we only have CI set up for Linux at the moment, so it's the most solid
@Matthew Griffith if you have mac issues, feel free to ping me
Lucas Rosa said:
Matthew Griffith if you have mac issues, feel free to ping me
Thanks! I will.
Hi all. Does the compiler still not work on Windows? I was just starting to go through the Building from Source page and it mentions Windows in the python spec, but it also lists libxkbcommon
as a requirement. (I also noticed another message recently about someone using WSL, which made me wonder if normal Windows didn't work.) Thanks :pray:
Is anyone up for a pairing/ensemble session to go through the Windows-or-WSL configuration? Maybe @Wolfgang Schuster, though you seem to be a few steps ahead already.
WSL should work, and I expect roc check
and roc edit
should work on normal Windows (although I haven't checked recently, and we don't currently have any Windows CI machines), but actually building or running a roc program (or the repl) on windows doesn't currently work because we don't have linking working there yet
we're currently in the process of overhauling how roc does linking; the new system works on Linux, and macOS development is partway there. Once it works on both of those and we've switched the compiler over to use it, then we can start on doing the same for linking Windows binaries and Web Assembly
@Richard Feldman, thanks for the information.
certainly! And I'd be happy to pair on getting at least roc check
and roc edit
building on Windows, since we'll at a minimum need those to work before building programs can work
@Luis Gutierrez I'd be happy to pair on using WSL as well. It was fairly straight forward. The only issues I ran into were that I'd installed Zig well over a year ago and that wasn't working anymore, so I had to re-install, and it took me a moment to get llvm installed correctly. I'm only running in WSL because I find it easier than in Windows for most development.
I'm free around 6:30pm Central Time or later
@Wolfgang Schuster, thanks that would be great. I'll switch to DM to arrange the logistical details, but if anyone else is interested in joining too, let us know.
@Richard Feldman, seems like there's maybe still value in doing the Windows (non-WSL) work for roc check
and roc edit
too, since that may be relevant for a different audience and maybe there's a need for some documentation about this more limited setup. If you agree, then I'll take you up on your pairing offer.
Last updated: Jul 06 2025 at 12:14 UTC