Build fails on nightly (12ed235ad 2018-07-18)

[zmitchell]

I'm on macOS 10.13.5, and I'm building artifact from source since there's no macOS binary (yet). Building from source gives me a number of errors, some of which I can fix.

Edit: I should add that I'm using the source code from the release page.

Missing cargo-web dependency

The first seems to be that cargo-web is required:

--- stdout
Build Script Started
Building artifact-frontend

--- stderr
error: no such subcommand: `web`

    Did you mean `new`?

thread 'main' panicked at 'artifact-frontend failed to build', build.rs:56:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I installed cargo-web separately via cargo install cargo-web and things progressed.

Bug in stdweb < 0.4.8

This is a known issue (see here), and has already been fixed in stdweb. All I needed to do was update Cargo.toml for artifact-frontend.

Incorrect paths used during build

I started running cargo check to speed things up, and I got this error message:

artifact-2.0.0!$ RUST_BACKTRACE=1 cargo check                                                                                  2m4s ~/Projects/artifact-2.0.0
   Compiling artifact-app v2.0.0 (file:///Users/zmitchell/Projects/artifact-2.0.0)
error: failed to run custom build command for `artifact-app v2.0.0 (file:///Users/zmitchell/Projects/artifact-2.0.0)`
process didn't exit successfully: `/Users/zmitchell/Projects/artifact-2.0.0/target/debug/build/artifact-app-7def9eec474743ad/build-script-build` (exit code: 101)
--- stdout
Build Script Started
Building artifact-frontend
Building the book

--- stderr
    Finished release [optimized] target(s) in 0.16s
    Garbage collecting "artifact-frontend.wasm"...
    Processing "artifact-frontend.wasm"...
    Finished processing of "artifact-frontend.wasm"!
The `artifact-frontend` was deployed to "/Users/zmitchell/Projects/artifact-2.0.0/artifact-frontend/target/deploy"!
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at libstd/sys_common/backtrace.rs:71
             at libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at libstd/panicking.rs:211
   3: std::panicking::default_hook
             at libstd/panicking.rs:227
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at libstd/panicking.rs:475
   5: std::panicking::continue_panic_fmt
             at libstd/panicking.rs:390
   6: std::panicking::try::do_call
             at libstd/panicking.rs:325
   7: core::ptr::drop_in_place
             at libcore/panicking.rs:77
   8: core::alloc::Layout::align
             at /Users/travis/build/rust-lang/rust/src/libcore/macros.rs:26
   9: <core::result::Result<T, E>>::unwrap
             at /Users/travis/build/rust-lang/rust/src/libcore/result.rs:782
  10: build_script_build::build_mdbook
             at ./build.rs:23
  11: build_script_build::main
             at ./build.rs:9
  12: std::rt::lang_start::{{closure}}
             at /Users/travis/build/rust-lang/rust/src/libstd/rt.rs:74
  13: std::panicking::try::do_call
             at libstd/rt.rs:59
             at libstd/panicking.rs:310
  14: panic_unwind::dwarf::eh::read_encoded_pointer
             at libpanic_unwind/lib.rs:106
  15: <std::sync::mutex::Mutex<T>>::new
             at libstd/panicking.rs:289
             at libstd/panic.rs:392
             at libstd/rt.rs:58
  16: std::rt::lang_start
             at /Users/travis/build/rust-lang/rust/src/libstd/rt.rs:74
  17: <build_script_build::FRONTEND_DEPLOY as core::ops::deref::Deref>::deref

As you can see, the panic is caused by unwrapping an error which is caused by a file/directory not being found. If you look at the backtrace, you'll see that the path /Users/travis/... is being used. I suspect that some CI stuff is leaking through to user installs, but I did verify that there's no travis user on my computer using dscl . list /Users | grep -v '^_'. I'm not sure where the travis part is leaking through though.

[marcb]

On Mac OS artifact-frontend/target/deploy/docs/ was created, but not on RHEL7…

mkdiring it allowed the build to continue but the contents were not added...

[vitiral]

Thanks everyone. Traveling and moving for the next few days so will not get to look at this for a bit

[adlan]

I have the same error (it seems so) and I think I might have found the reason.

I poke around in build.rs, looking at the code surrounding the "Building the book" message. I noticed that the task calls mdbook and I cannot find that executable in my path.

I installed mdbook, and the error is gone when I re-run the build (I have also applied the stdweb update as mentioned by @zmitchell above).

Stacktrace:

❯ RUST_BACKTRACE=1 cargo build --release
   Compiling artifact-app v2.0.0 (file:///Users/adlan/Sandbox/artifact)
error: failed to run custom build command for `artifact-app v2.0.0 (file:///Users/adlan/Sandbox/artifact)`
process didn't exit successfully: `/Users/adlan/Sandbox/artifact/target/release/build/artifact-app-19442d518efed9dc/build-script-build` (exit code: 101)
--- stdout
Build Script Started
Building artifact-frontend
Building the book

--- stderr
    Finished release [optimized] target(s) in 0.14s
  5     deep_copy(
    Garbage collecting "artifact-frontend.wasm"...
    Processing "artifact-frontend.wasm"...
    Finished processing of "artifact-frontend.wasm"!
  7 #[macro_use]
The `artifact-frontend` was deployed to "/Users/adlan/Sandbox/artifact/artifact-frontend/target/deploy"!
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', libcore/result.rs:945:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: build_script_build::main
  10: std::rt::lang_start::{{closure}}
  11: std::panicking::try::do_call
  7 #[macro_use]
  12: __rust_maybe_catch_panic
  13: std::rt::lang_start_internal
  14: main

Installed toolchains:

❯ rustup show
Default host: x86_64-apple-darwin

installed toolchains
--------------------

stable-x86_64-apple-darwin
nightly-x86_64-apple-darwin (default)

installed targets for active toolchain
--------------------------------------

wasm32-unknown-unknown
x86_64-apple-darwin

active toolchain
----------------

nightly-x86_64-apple-darwin (default)
rustc 1.29.0-nightly (54628c8ea 2018-07-30)

[zmitchell]

This fixed it for me too. So, to summarize:

• Add cargo-web as a dependency.
• Update the stdweb version to 0.4.8 in artifact-frontend.
• Add mdbook as a dependency.

[vitiral]

Thanks for the detailed bug reports everyone!

I've done what @zmitchell suggested, as well as add checks in build.rs for the dependencies with a better error message. I hope to have better build/release mechanisms in the next few months... but as I just started a new job it's going to be a while without contributor help.

This goes a long way. If anyone is interested in becoming a contributor to spearhead getting this building+releasing on multiple platforms I would be very interested!

[vitiral]

fixed in 2674c7cfd042071af8b1304039dd647a443aca7e (hopefully)

[zmitchell]

I've never done anything like that, but I'm willing to give it a go!

[vitiral]

Cool, if you've got the time and desire i could definitely use the help :)

• sent from my Android

On Sun, Aug 5, 2018, 9:40 AM Zach Mitchell notifications@github.com wrote:

I've never done anything like that, but I'm willing to give it a go!

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/vitiral/artifact/issues/236#issuecomment-410532178, or mute the thread https://github.com/notifications/unsubscribe-auth/AFVCy--TO0VBsJ2o38rtxkgUp1PIFa-zks5uNyAGgaJpZM4VZtlv .