Building from source on windows

[visceralfield]

Hello,

I'm interested in using Artifact for a project, but I'm developing on Windows. I downloaded the source and have attempted to compile - both mdbook and cargo-web are installed, but even with both of them in place, any post-2.0 release of artifact fails to build with the following error:

   Compiling artifact_lib v0.1.0 (C:\Users\Josh\Documents\GitHub\artifact\artifact-lib)
error: failed to run custom build command for `artifact-app v2.1.0 (C:\Users\Josh\Documents\GitHub\artifact\artifact-app)`

Caused by:
  process didn't exit successfully: `C:\Users\Josh\Documents\GitHub\artifact\target\release\build\artifact-app-725f2e4ceebe7093\build-script-build` (exit code: 101)
--- stdout
Build Script Started
Checking dependencies

--- stderr
thread 'main' panicked at 'which/where doesn't exist: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified." }', src\libcore\result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

warning: build failed, waiting for other jobs to finish...
error: build failed

The backtrace seemed pretty long and unhelpful. The most prominent note in it was several occurences of unresolved external symbol emscripten_asm_const_int. If someone is willing to point me in the right direction, I'd love to do what needs to get done to get this working.

[vitiral]

This is the cause of the failure:

thread 'main' panicked at 'which/where doesn't exist: Os { code: 2, kind: NotFound, message: "The system cannot find the file specified."

Neither which nor where exists on your system, or there is a bug with artifact's build system.

[visceralfield]

I am running windows 10, within PowerShell. where has known issues in powershell (see here) I am assuming artifact's build system attempts to use which on UNIX and where on Windows? I am unsure if using powershell is the root of my issue here, I will do some investigation in a fork and report back.

[visceralfield]

@vitiral I have created a workaround in the build script which allows successful compilation. See master...Josh-Thompson:master . Would you like me to submit a PR? It seems like a workaround is needed because std::process::Command.current_dir() dies if you give it a path in extended length path syntax... which is the syntax std::path::Path provides 🤦‍♂. I plan to do some further testing on that issue tonight, ensure it really is broken the way I think it is, and then submit an issue with the Rust language team, but for now this workaround enables compilation on Windows.

I am now stuck on linking artifact-frontend. I have cargo-web installed, do I need to modify anything else? I am getting several occurences of error LNK2001: unresolved external symbol emscripten_asm_const_int.

[vitiral]

Hey Josh, thanks for looking into this. It is really helpful to have someone with windows who can triage issues.

I would love a PR. I'm not totally sure what the code around mdbook_dir is doing (why is there a regex?), but I'd be interested in what changes are needed to get things working.

The build phase is in https://github.com/vitiral/artifact/blob/master/ci/script.sh

I think you need to do the following:

    cargo-web deploy -p artifact-frontend --release --target=wasm32-unknown-unknown
    cargo build -p artifact-app

Sorry if that wasn't completely clear. I used to do this within build.rs but then things weren't working (IIRC they weren't working for windows for some reason).

[visceralfield]

Hi again! Happy to help. To give some insight into why that regex is there - Windows paths usually look like X:\path\to\place, where X is a drive letter. There are however variations. See this link for specific details: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation but basically, the way to ensure a path that might be too long for old windows API doesn't break stuff is to prefix it with \\?\, so you get something like \\?\X:\path\to\place. Programming languages usually then escape these slashes, so your string is \\\\?\X:\\path\\to\\place. This is all well and good - except that only some Windows API actually supports this extended syntax.

My regex workaround is to grab the string starting only from the first alphabetical character, i.e. the drive letter. This ensures that rust doesn't break trying to pass that to std::process::Command. Hope that makes sense.

[visceralfield]

Using cargo-web deploy before doing cargo-build like that worked successfully! I was able to fully compile the project :)

[visceralfield]

PR #270 opened for this 😄