koute / cargo-web Goto Github PK
View Code? Open in Web Editor NEWA Cargo subcommand for the client-side Web
License: Apache License 2.0
A Cargo subcommand for the client-side Web
License: Apache License 2.0
Currently, it is not possible to integrate stdweb/cargo-web crates into a webpack-based project without a few modifications.
I came across the following hiccups in the process:
Since Webpack uses NodeJS the wasm_runtime.js
goes into the wrong branch and attempts to load NodeJS modules during the webpack build process which fails because webpack replaces the calls to require (indirectly) with the required module which fails and shouldn't have happened in the first place.
The path to the wasm file is currently hardcoded to the webroot but it may be desirable to either:
a. Use a configurable path which may or may not be the webroot.
b. Use a webpack file-loader to bundle the wasm code at build time by using the wasm-loader possibly in combination with the rust-native-wasm-loader.
Note: Attempt documented two comments below.
When server-side rendering is used the wasm modules won't load on the server when 2.a is used and the wasm_runtime.js
is included in the webpack bundle. It fails with the following error message:
Error loading Rust wasm module 'rtvcs_web': Error: only absolute URLs are supported
Additionally, it would be nice to have a webpack-loader that somehow integrates cargo-web into a webpack project.
Note: This all corresponds to the wasm32-unknown-unknown
target.
Seemingly it is not possible to run cargo web build --features="someFeature"
.
Would be nice to have!
I'd love to see a command or arg that allowed building the app into a deployable package. Today I use this build script. Something like cargo-web package
or maybe just cargo-web build -d <outdir> --release
.
I'd love to see support for https://www.hellorust.com/news/native-wasm-target.html in cargo-web; I think it's going to be an even bigger target than the emscripten one.
Basically see title. I'm using Arch Linux and have emscripten and binaryen installed and working using provided packages but cargo-web still tries to download these. Can't it use system packages?
^ Title
I'd like to use my own custom index.html
when starting the cargo web server.
Auto reload would be handy for my kind of development.
Cargo-web could provide a websocket which pushes a notification when a newly compiled result is available. (Automagically injected?) Browser Side JS would listen and decide whether to reload or not. It would be enabled via a command line flag, e.g. --recompile-status
.
I'm hacking on this code. If I run:
cargo web build --target-webasm-emscripten
The project builds fine. If I run:
cargo web build --target-webasm-emscripten --release
the build fails with screens of errors, at the top of which is:
= note: WARNING:root:emcc: cannot find library "SDL2"
The errors look like so:
WARNING:root:object /tmp/emscripten_temp_3wyyWe_archive_contents/ncollide-cfdd2aa6ffc25dc6.ncollide0.rust-cgu.bytecode.encoded is not valid, cannot link
This is with a stock Emscripten environment under Linux (I.e. the prebuilt 1.37.27 binaries.) No other change is made in the environment beyond adding --release
to the build command, and I'm using latest Rust stable.
This is something I'm not sure where the problem lies in as I found it via testing yew but it appears that while a source map is generated, neither Chrome or Firefox can find it. Maybe this isn't a problem with cargo-web and might be a misconfiguration of yew. I'm building with the emscripten target and not the built-in WASM from Nightly currently (using stable Rust from Rustup)
I tried compiling my Rust application with --target-webasm-emscripten
but when I ran it, I got this runtime error:
Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher
than the current value 16777216, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which allows
increasing the size at runtime but prevents some optimizations, (3) set Module.TOTAL_MEMORY
to a higher value before the program runs, or (4) if you want malloc to return NULL (0)
instead of this abort, compile with -s ABORTING_MALLOC=0
According to the Emscripten docs, you can use ALLOW_MEMORY_GROWTH to fix this.
I recommend adding -s ALLOW_MEMORY_GROWTH=1
by default to the emcc
command, since it has little to no downside on WebAssembly.
I get this:
RUST_BACKTRACE=1 cargo web start --target-webasm-emscripten --use-system-emscripten
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "No such file or directory" } }', /checkout/src/libcore/result.rs:916:4
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at /checkout/src/libstd/sys_common/backtrace.rs:68
at /checkout/src/libstd/sys_common/backtrace.rs:57
2: std::panicking::default_hook::{{closure}}
at /checkout/src/libstd/panicking.rs:381
3: std::panicking::default_hook
at /checkout/src/libstd/panicking.rs:397
4: std::panicking::rust_panic_with_hook
at /checkout/src/libstd/panicking.rs:577
5: std::panicking::begin_panic
at /checkout/src/libstd/panicking.rs:538
6: std::panicking::begin_panic_fmt
at /checkout/src/libstd/panicking.rs:522
7: rust_begin_unwind
at /checkout/src/libstd/panicking.rs:498
8: core::panicking::panic_fmt
at /checkout/src/libcore/panicking.rs:71
9: core::result::unwrap_failed
10: cargo_web::command_start
11: cargo_web::main
12: __rust_maybe_catch_panic
at /checkout/src/libpanic_unwind/lib.rs:101
13: std::rt::lang_start
at /checkout/src/libstd/panicking.rs:459
at /checkout/src/libstd/rt.rs:58
14: __libc_start_main
15: _start
but cargo web start --target-asmjs-emscripten --use-system-emscripten
works just fine. My system has emscripten 1.37.25 and binaryen 40 installed.
On top of fixing this error, I'd like to note that you should probably rather use an expect
there instead of an unwrap
so that people know what's wrong exactly.
I'd like to download Emscripten, then run commands in the downloaded installation to install ports. This is for a CI environment generating automated builds.
I don't see a way to do this other than triggering a build, which will fail since the environment lacks the necessary tools, then using the freshly-installed Emscripten to set up the environment for a second build that succeeds. A download
command would help with that. Or maybe an emscripten
command so other subcommands might be added in the future. I don't care much about what the command is called, as long as I can just download whatever Emscripten version cargo-web supports so I can install ports before building. :)
Thanks.
When compiling my Rust application with --target-asmjs-emscripten
I ran into some situations where there are APIs which are simply not supported in JS (such as threads), which then causes a runtime panic.
I would like to be able to compile my application for use on either the desktop (with full support) or JS / Wasm (without support for things like threads) and conditional compilation seems like a good way to accomplish that.
However, I wasn't able to find a way to do that. The --features
flag doesn't work, and I couldn't find whether cargo-web
sets a special config flag when compiling. Is conditional compilation supported, or planned to be supported?
P.S. I'm a JavaScript expert, learning Rust, and I would really like to be able to use Rust on the web, so I'm interested in helping out with pull requests.
Oh... guys, half of humanity really needs this tool, but it is totally ungooglable! I've just reinvented the wheel to solve the same problem, but then found your excellent solution.
And yes, "stdweb" have the same problem, I assure you.
Right now if you launch cargo web test
it will launch your tests in a new Chrome/Chromium instance it finds installed on your system. This is a huge hack which should be replaced by a proper headless browser (either headless Chromium or headless Firefox, or even both, because cross browser testing is important).
cargo-web
automatically download and install it.$ RUST_BACKTRACE=1 cargo web start --target-webasm-emscripten
Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { repr: Os { code: 2, message: "No such file or directory" } }', /checkout/src/libcore/result.rs:906:4
stack backtrace:
0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
1: std::sys_common::backtrace::print
at /checkout/src/libstd/sys_common/backtrace.rs:68
at /checkout/src/libstd/sys_common/backtrace.rs:57
2: _ZN3std9panicking12default_hook28_$u7b$$u7b$closure$u7d$$u7d$17hef59f1d15185c20fE.llvm.272A3273
at /checkout/src/libstd/panicking.rs:381
3: _ZN3std9panicking12default_hook17h7cc618db9a2c6232E.llvm.272A3273
at /checkout/src/libstd/panicking.rs:397
4: std::panicking::rust_panic_with_hook
at /checkout/src/libstd/panicking.rs:577
5: _ZN3std9panicking11begin_panic17hd8d93c98c4fac2daE.llvm.272A3273
at /checkout/src/libstd/panicking.rs:538
6: std::panicking::begin_panic_fmt
at /checkout/src/libstd/panicking.rs:522
7: rust_begin_unwind
at /checkout/src/libstd/panicking.rs:498
8: core::panicking::panic_fmt
at /checkout/src/libcore/panicking.rs:71
9: core::result::unwrap_failed
10: cargo_web::command_start
11: cargo_web::main
12: __rust_maybe_catch_panic
at /checkout/src/libpanic_unwind/lib.rs:101
13: std::rt::lang_start
at /checkout/src/libstd/panicking.rs:459
at /checkout/src/libstd/rt.rs:58
14: __libc_start_main
15: _start
When using this tool combined with common web infrastructure such as webpack, it's useful to be able to control how the wasm file is loaded from Javascript instead of hardcoding a fetch call.
It might be useful to use the native wasm support in Webpack 4 for example, where the exports from a wasm file can be imported simply using import {myfunction} from "bla.wasm";
We might also want to put the wasm file on a CDN or integrate it with a service worker asset loader etc. which also requires being able to customize the wasm file url.
Right now I do this by search replacing the generated url like so: https://github.com/dflemstr/rust-native-wasm-loader/blob/f30905197637b7e3dbccfdd1ac61a43709d395d5/index.js#L68
I have Windows7 64-bit. I fired this command cargo install cargo-web
. I am using rustc 1.23.0.
I am getting an error -
error: linking with
link.exe failed: exit code: 1181 | = note: "C:\\Program Files (x86)\\Microsoft Visual Studio 11.0\\VC\\bin\\amd64\\link.exe" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\ \Users\\VISHAL\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "C:\\Users\\VISH AL\\AppData\\Local\\Temp\\cargo-install.VN2UTPu1F7E5\\release\\deps\\cargo_web-fdfc46013556d8f2.cargo_web0.rcgu.o......
= note: LINK : warning LNK4044: unrecognized option '/NATVIS:C:\Users\VISHAL\.rustup\toolchains\stable-x86_64-pc-windows-msvc \lib\rustlib\etc\liballoc.natvis'; ignored LINK : warning LNK4044: unrecognized option '/NATVIS:C:\Users\VISHAL\.rustup\toolchains\stable-x86_64-pc-windows-msvc \lib\rustlib\etc\libcore.natvis'; ignored LINK : fatal error LNK1181: cannot open input file 'synchronization.lib' error: aborting due to previous error error: failed to compile
cargo-web v0.5.2, intermediate artifacts can be found at
Currently, using some math functions e.g. (1.0 as f64).sin()
with wasm results in a runtime error.
I'm not sure whose "fault" it is, nor where the best place to solve it is; but, one way is to provide these functions in the import
section when instantiating the wasm module.
env: {
// ...
"sin": Math.sin
"cos": Math.cos
// ...
}
I'm not that familiar with wasm-JS interop, so this could be horribly inefficient. But, is slow worse than broken?
Technically this has its root cause in another crate, but may require upgrading another package version to get the fix.
I get
error[E0583]: file not found for module `montgomery`
in ring v0.11.0 when trying to install with rustup override set to nightly for the directory. It looks like this is fixed at least in ring 0.13.0:
briansmith/ring#598
If I install with stable, it runs fine.
With the latest release of cargo-web
, the output on PowerShell looks like this:
I don't remember this being an issue with the 0.4.x series, but I can't remember if I actually tested the 0.4.x series on my Windows computer, or if I had merely installed it here. I know I had played with cargo web
on my Linux laptop. Either way, the colors seem to be broken now.
Hi, I can't get static files to be served, no matter what path I try, is there anything that isn't in documentation I should be aware of to get it working?
I'm interested in packaging this application. To do that I would need you to create tags when releasing a new version. This causes github to create a .tar.gz for those tags that I can use to build the package. :)
I have a project with workspace, one of the workspace member is using cargo-web.
Outside the workspace it works fine, but if it's inside workspace member it's panicking. Both asmjs and wasm32 is panicking.
[workspace]
members = [
"server/",
"client/"
]
RUST_BACKTRACE=1 cargo web start --target wasm32-unknown-emscripten
thread 'main' panicked at 'Unknown target kind: 'dylib'', src/cargo_shim/mod.rs:236:38
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:380
3: std::panicking::default_hook
at libstd/panicking.rs:396
4: std::panicking::rust_panic_with_hook
at libstd/panicking.rs:576
5: std::panicking::begin_panic
at libstd/panicking.rs:537
6: std::panicking::begin_panic_fmt
at libstd/panicking.rs:521
7: <core::iter::FilterMap<I, F> as core::iter::iterator::Iterator>::next
8: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
9: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &'a mut F>::call_once
10: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T, I>>::from_iter
11: cargo_web::cargo_shim::CargoProject::new
12: cargo_web::build::BuildArgs::load_project
13: cargo_web::cmd_start::command_start
14: cargo_web::main
15: std::rt::lang_start::{{closure}}
16: std::panicking::try::do_call
at libstd/rt.rs:59
at libstd/panicking.rs:479
17: __rust_maybe_catch_panic
at libpanic_unwind/lib.rs:102
18: std::rt::lang_start_internal
at libstd/panicking.rs:458
at libstd/panic.rs:358
at libstd/rt.rs:58
19: main
20: __libc_start_main
21: _start
When using cargo web
in a script or from a different tool it would be great to get log output as line separated JSON objects so that they can be parsed into meaningful data to be displayed to the user.
Normal cargo already supports this so I guess it's only a question of passing through a flag and maybe logging additional things from this tool (such as the location of generated js files)
I want to add support for richer error handling in https://github.com/dflemstr/rust-native-wasm-loader and lacking support for this makes things harder than necessary.
I'm porting a single page app from polymer to yew and I had a gulp task that uses browser-sync to auto reload but also proxy request to "/api" to the real backend server, how can I do that with cargo web?
If it doesn't support proxy, how can I tell cargo web to only build on source change (so that I can use browser-sync to watch the build output and use that for proxying, like I do with PureScript)?
It would be helpful to add a subcommand that generates default static content at the correct path. I'd like to modify the default HTML, but am not immediately sure what it should look like. I suppose I could wget the result of cargo web start
, but I don't know what parts of that are needed in the static directory and what aren't.
Further, I thought cargo web build
would output everything I'd need to host a wasm app on a static site, but I can't find any HTML to post. Maybe I'm fundamentally misunderstanding something about how to host an app?
Thanks.
As we can see in travis log, cargo install cargo-web
takes about 10 minutes. It can be much faster if we will just download a compiled binary. It is done by "just" utility, for example.
Hi on trying to run cargo install cargo-web on macos I get the following error:
Compiling app_dirs v1.1.1
error[E0619]: the type of this value must be known in this context
--> /Users/rebo/.cargo/registry/src/github.com-1ecc6299db9ec823/app_dirs-1.1.1/src/imp/platform/macos.rs:10:40
|
10 | Ok(Component::RootDir.as_ref().into())
| ^^^^
error: aborting due to previous error
Any ideas?
As far as I can tell this is not done currently, but it should be simple to integrate.
Is this on the roadmap at all?
Seems like this used to work, but it no longer does, and the -v
option doesn't provide any clarity. Running the V0.6.0 release under Linux.
Thanks!
Hey @koute , is it possible to make cargo web deploy
to output to target-dir
?
https://doc.rust-lang.org/cargo/reference/config.html
I've configured cargo target-dir
but it always output to current cargo dir. Or is it possible to specify output dir like cargo web deploy --output /some/dir
?
Do you think a cargo web node
makes sense to launch the .js
file with node?
The command cargo install cargo-web
,
after a minute and half of compiling, printed:
error: failed to run custom build command for `openssl-sys v0.9.24`
process didn't exit successfully: `/tmp/cargo-install.aKdf8gWcEAu5/release/build/openssl-sys-5ee2bfe045b42a7a/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
cargo:rerun-if-env-changed=OPENSSL_DIR
run pkg_config fail: "`\"pkg-config\" \"--libs\" \"--cflags\" \"openssl\"` did not exit successfully: exit code: 1\n--- stderr\nPackage openssl was not found in the pkg-config search path.\nPerhaps you should add the directory containing `openssl.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'openssl\' found\n"
--- stderr
thread 'main' panicked at '
Could not find directory of OpenSSL installation, and this `-sys` crate cannot
proceed without this knowledge. If OpenSSL is installed and this crate had
trouble finding it, you can set the `OPENSSL_DIR` environment variable for the
compilation process.
If you're in a situation where you think the directory *should* be found
automatically, please open a bug at https://github.com/sfackler/rust-openssl
and include information about your system as well as this message.
$HOST = x86_64-unknown-linux-gnu
$TARGET = x86_64-unknown-linux-gnu
openssl-sys = 0.9.24
The command which openssl
prints /usr/bin/openssl
, and so I tried also the command OPENSSL_DIR=/usr/bin cargo install cargo-web
, getting the following output:
error: failed to run custom build command for `openssl-sys v0.9.24`
process didn't exit successfully: `/tmp/cargo-install.FbQ5fWKqfqMJ/release/build/openssl-sys-5ee2bfe045b42a7a/build-script-build` (exit code: 101)
--- stdout
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=OPENSSL_LIB_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=OPENSSL_INCLUDE_DIR
cargo:rerun-if-env-changed=X86_64_UNKNOWN_LINUX_GNU_OPENSSL_DIR
cargo:rerun-if-env-changed=OPENSSL_DIR
--- stderr
thread 'main' panicked at 'OpenSSL library directory does not exist: /usr/bin/lib ...
Right now if I push to /page
and reload it will 404. If the behaviour to opt in to history api fallback (as is implemented for webpack-dev-server) with a flag could be implemented, that would be awesome!
Looking at the code now it just tries to match /
or /index.html
. I think this could be moved to the last match if the flag was present, to try and pick off the other routes first.
I followed the steps here and it worked with the hello.rs to hello.js with rustc --target asmjs-unknown-emscripten hello.rs
but now I'm trying to build a yew example and it says emscripten is not installed, why?
D:\3rdparty\yew\examples\counter>"d:\Program Files\emsdk-portable-64bit\emsdk_env.bat"
Adding directories to PATH:
PATH += d:\Program Files\emsdk-portable-64bit
Setting environment variables:
EMSDK = d:/Program Files/emsdk-portable-64bit
EM_CONFIG = C:\Users\me\.emscripten
D:\3rdparty\yew\examples\counter>cargo web start
error: you don't have Emscripten installed!
Download and install emscripten from the official site: http://kripken.github.io/emscripten-site/docs/getting_started/downloads.html
(I have to use asmjs instead of wasm to support old browsers.)
EDIT: The hello.rs example worked in the emscripten sdk folder, but when I copy the hello.rs file to another folder and start a cmd.exe there and then run rustc --target asmjs-unknown-emscripten hello.rs
I get note: 'emcc.bat' is not recognized as an internal or external command, operable program or batch file.
even though I ran emsdk_env.bat
in that shell, why?
My Cargo.toml contains these lines:
[target.'cfg(target_arch = "wasm32")'.dependencies]
stdweb = "0.3"
[target.'cfg(not(target_arch = "wasm32"))'.dependencies]
glutin = "*"
But when i use cargo web build --target-webasm to build, it still be referenced glutin.
Did i do something wrong ? Or how can switch between normal arch and wasm32 one ?
This will probably get easier once Webpack or some other tool is better integrated, but right now I'm manually building a static PWA page for loading my assets. One minor gotcha is that, in development mode, the loader is served up as /js/app.js, while the release build seems to create files named my_crate.{js,wasm}.
I understand that this is fairly easy to mitigate by moving some files, but I wonder if a better solution might be serving up the files at /my_crate.{js,wasm} in development mode too? Then I could use the regular static assets unmodified between development and production if I like, simply copying src/static into the target directory and publishing that to my server.
I'm willing to try taking this on, I just want to know if there's some gotcha related to serving up assets based on their target name rather than the generic /js/app.js. Thanks.
Hi, thanks for implementing the new deploy command! :) On a new project, I ran cargo web deploy...
to get a fresh template. I then edited it, added links to CDN-hosted stylesheets, and placed it in src/static.
It's surprising to me that the deploy command doesn't respect src/stattic. Running it again gives me a fresh template in target/deploy.
In cases where src/static exists, I'd expect cargo web deploy
to copy over index.html, as well as any other files contained therein, and only overwrite index.html if it is missing.
Thanks!
I just started with cargo web
and I noticed that if I run commands multiple times (e.g. cargo web test
) that because artifacts in target/
have not changed cargo-web
panics:
$ cargo web test --nodejs --target-webasm
warning: debug builds on the wasm-unknown-unknown are currently totally broken
forcing a release build
Finished release [optimized] target(s) in 0.0 secs
thread 'main' panicked at 'internal error: nothing changed so I don't know which artifact corresponds to this build', /Users/stephen/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-web-0.4.0/src/main.rs:830:16
note: Run with `RUST_BACKTRACE=1` for a backtrace.
Working around this issue is easy enough, as it turns out: I just needed to modify my code in some way before running the command again. But the error message here was not obvious to me initially, and so it had me searching online for solutions without finding anything.
Being able to configure emscripten ports would be nice, possibly with features
Otherwise the user needs to go an manually run
embuilder.py build all
and set EMMAKEN_CFLAGS
<!DOCTYPE html>
<head> <!-- Notice missing <html> -->
<meta charset="utf-8" />
<body>
<script src="tts.js"></script>
</body>
</html>
I tried splitting a project into a cargo workspace, and found an odd issue. I separated my project into a local library crate that the main project depends on.
[package]
# ...
[workspace]
members = ["./local-lib"]
[dependencies]
local-lib = { path = "./local-lib" }
stdweb = "*"
after doing this, "cargo web start" throws the following error
$ cargo web start
error: cannot start a webserver for a crate which is a library!
I fixed it by removing the workspace section in the toml
[package]
# ...
[dependencies]
local-lib = { path = "./local-lib" }
stdweb = "*"
It seems like it thinks that the main project is a different type of crate when the workspace tag is set, but I think this is a perfectly valid setup for a workspace. is there any reason why cargo-web rejects this?
chrome.exe --version
does not print out version information on windows, it just launches a new window. You can use which
/where
to check whether a command exists without running it - there's an implementation in rustup you can steal.
If I start a server using cargo web start
it correctly builds the package and launches a server with a working page. But if I change anything and a rebuild is triggered it errors with:
error: could not exec the linker `emcc`: No such file or directory (os error 2)
|
= note: "emcc" "-s" "DISABLE_EXCEPTION_CATCHING=0" "-L" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/catalyst-ad556bdccbf1bed8.0.o" "-o" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/catalyst-ad556bdccbf1bed8.js" "-s" "EXPORTED_FUNCTIONS=[\"_main\",\"___rdl_shrink_in_place\",\"___rdl_alloc_excess\",\"___rdl_usable_size\",\"___rdl_alloc\",\"___rdl_realloc_excess\",\"___rdl_realloc\",\"___rdl_oom\",\"___rdl_grow_in_place\",\"___rdl_alloc_zeroed\",\"___rdl_dealloc\",\"_rust_eh_personality\"]" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/catalyst-ad556bdccbf1bed8.crate.allocator.o" "-O0" "--memory-init-file" "0" "-g4" "-s" "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=[]" "-L" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps" "-L" "/home/rasmus/Development/catalyst/target/debug/deps" "-L" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libcatalyst-b47ad62f78790a7a.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libstdweb-7bfa732ce4e281cb.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libserde_json-2e6a65e2f75759e0.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libdtoa-49eaf858ed5bb53b.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libitoa-9afcb23e92bf9413.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libserde-c29e90fe3a0f30b7.rlib" "/home/rasmus/Development/catalyst/target/asmjs-unknown-emscripten/debug/deps/libnum_traits-379830a7c273381b.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libstd-881b9fdbdf1d515b.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/liballoc_system-3c10208cdd7e61cb.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/librand-32f648f7f7567c6c.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libpanic_unwind-9cbadc6554202be9.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libunwind-618c266cf9124966.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/liblibc-16f3b02b9a976b94.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/liballoc-bc70b4efeaeb398c.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libstd_unicode-a0ad42dc8f5856aa.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libcore-21491ce3d14f1ef2.rlib" "/home/rasmus/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/asmjs-unknown-emscripten/lib/libcompiler_builtins-b9713bd7f605c0b2.rlib" "-l" "c" "-s" "ERROR_ON_UNDEFINED_SYMBOLS=1"
error: aborting due to previous error
Is there some path magic that is applied the first build but not for the rest of the builds?
generate multiple js files. each html files can han one or other js file. Currently supported?
another Currently supported SPA?
So I know I can use Web.toml to define link-args = ["-s", "ASYNCIFY=1"]
but that's not the issue here. I get this with either link-args = ["-s", "ASYNCIFY=1"]
in Web.toml or EMMAKEN_CFLAGS="-s ASYNCIFY=1" cargo web build --target-wasm-emscripten --use-system-emscripten --release
:
log.txt
Without that line or env var it works fine. However! EMMAKEN_CFLAGS="-s ASYNCIFY=1" cargo build --target wasm32-unknown-emscripten --release
works just fine and has the desired effect. What's up here?
Right now if you use cargo web start
it will automatically re-build if the files change, which is great!
But I'm developing a Chrome Extension, so cargo web start
doesn't work for me (because the compiled files are loaded into the browser, not displayed on an HTML page).
So it would be great if I could do cargo web build --watch
, cargo web deploy --watch
, and cargo web test --watch
When using the --watch
option it will watch for file changes (just like cargo web start
) and will then re-run cargo web build
(or cargo web deploy
/ cargo web test
) automatically.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.