I followed the tutorialenter link description here to this step，
make build
WASM_BUILD_TOOLCHAIN=nightly-2020-10-05 cargo build --release
Compiling node-template-runtime v2.0.0 (/home/wangliqiu2021/CLionProjects/substrate-node-template/runtime)
Building [=====================================================> ] 857/861: node-template-runtime(build)
Cargo has been executed for a long time(almost one+ hour) without ending,It seems to be stuck, does anyone know the reason？help me
OS：Ubuntu 20.04
CPU: AMD Ryzen 7 1700 Eight-Core Processor
The compile is not stuck in compilation, it is just taking a while due to the 800+ dependencies. From #gnunicorn on this github issue:
Rust isn't particular quick with the compiling at the moment and opaque to the person in front, at this step (when compiling node-template-runtime) we are actually building the project twice: once natively and once in wasm. So at some step in between it appears as if nothing happens and that can take up to half the total build time – if the other part took e.g. 10minutes then this process might take another 10min without any indicator of process (other than the CPU pumping hard).
You are doing a release build (cargo build --release) which enables optimizations. For development purposes, a regular build or just a cargo check will be substantially faster.
Some comments in the linked GitHub issue mentioned that running a cargo clean and rebuilding helped speed up compile times, so you can try that as well.
From your username. I think you are in China, same as me.
node-template-runtime(build) means you're compiling the runtime into a wasm file. During this, it might need a download (so try to use a VPN).
The download only happened in 1.0.0 https://docs.rs/substrate-wasm-builder/1.0.0/substrate_wasm_builder/?search=
Also, the wasm compiling will take a long time too (depend on your hardware).
In the 2016 MacBookPro, the whole compiling takes 30mins.
Moreover, there might be a bug in that build.rs. Sometimes I've to run cargo clean. If I interrupt the compiling while node-template-runtime(build).
I found the reason.
$CARGO_HOME/config.toml:
[build]
target-dir = "target"
remove it.
In my case the issue was, that the WASM runtime build expects to find the WASM files inside the local target directory.
If the build can't find the local WASM files in the target directory - it just hangs or deadlocks (e.g. GitHub issue).
I had to change the target-dir setting in ~/.cargo/config.toml.
You can also override the global setting with a local env var:
CARGO_TARGET_DIR=target cargo build
Or you can use the cargo CLI flags:
cargo build --target-dir=target
Note that some of the wasm-builder based build scripts ignore the CARGO_TARGET_DIR env variable (e.g. wasm_project.rs).
Related
For some reason Rust Analyzer isn't generating a warning for undefined variables. Do I need to tweak some settings somewhere?
I'm also not getting warnings for unused variables, unimported crates, etc.
Edit: Tested this out with a new workspace. Both cargo check and Rust Analyzer work. It reports a single intentional error. When I run cargo check in the first workspace, it reports a lot of errors in the ~/.cargo directory, and none in the current workspace. Perhaps a crate I am using has errors and is locking up cargo check before it can get around to checking the files in my directory?
The log when running cargo check showed some issues with ~/.cargo/registry/src/github.com-xx..xx/rppal-0.12.0. This came from a the crate rust_gpiozero that I had listed as a dependency. As best as I can figure, cargo check was failing on this and then ceasing to analyze my files. After removing this dependency, both cargo check and Rust Analyzer run as expected.
Cheers to all who replied to this thread for their guidance.
Rust-analyzer itself doesn't produce errors or warnings for this.
If you want warnings and errors, enable the "Check on Enable" option in the rust-analyzer extension. This will run cargo check every time you save a Rust file and display the emitted warnings and errors in the files.
For another possible cause: try cargo clean.
This problem happened to me after upgrading my toolchain version. As mentioned in other answers, running cargo check yielded many errors. The topmost error mentioned a crate "compiled by an incompatible version of rustc." Running cargo clean followed by cargo check fixed all errors.
I work on a Rust project that has a lot of packages as explicit or implicit dependencies (~420). When I want to rebuild the target after changing the .env file (that configures things like IP to download files from), I would like to rebuild only the packages that I authored, not all the dependencies.
How can I tell cargo build to use the previously compiled dependencies, but not use the previously compiled package that uses the .env file as input?
Ideally, cargo build would realize that the .env file has changed and automatically decide to rebuild only the parts that use the .env file, but unfortunately this doesn't seem to be the case.
So the second best solution is to manually tell cargo build at which point in the build graph to start off again.
We're using the dotenv crate https://crates.io/crates/dotenv crate to read the .env file.
I tried cargo clean -p nextclade to tell it to clean only the package in question that I'm working on - but that still cleans up all the dependencies which cause my build to take 5 minutes rather than 2 minutes (if using compiled dependencies).
There's a question that seems to ask a similar question, but that question is actually a different use case/set up, so it's not a duplicate: How does cargo decide whether to rebuild the deps or not?
Several builds, like this one, fail when executing cabal check:
++cabal check
These warnings may cause trouble when distributing the package:
* 'ghc-options: -O2' is rarely needed. Check that it is giving a real benefit
and not just imposing longer compile times on your users.
However, most of the other builds in the matrix do not fail after this check.
I'm using the complex Travis configuration suggested at the stack docs, and this is the Travis configuration specific for the project I'm trying to get on CI.
Any ideas on what might be causing this behavior?
There are two types of build in your travis config:
Stack based build
Cabal based build
If you follow the script code, you will see that only Cabal based build has the command cabal check in it. That will explain why all of your Stack based builds are working fine. Now, let's see the cabal check command line in detail:
cabal check || [ "$CABALVER" == "1.16" ]
So, if your installed cabal version is 1.16, it will ignore the output of cabal check and that command is treated as a success. And infact, that's what is happening. Only one Cabal based build job is success in your travis, because it's version is 1.16.
My project contains third-party library sources that located in separate directory:
/prj
/src
/app
/lib1
/lib2
/third-party-lib
SConscript
...
SConstruct
Compiling of the third-party-lib is quite long because of large library size. I'm never change the sources of the library and the only case when the library needs to be rebuild is changes of the build options (compiler flags, for example).
To rebuild the project I issue commands:
scons -c && scons
In this case SCons removes all build products including the third-party-lib and subsequent build consumes a significant time due to third-party-lib compiling which, as said above, never changed. Method:
lib = env.StaticLibrary(Target, obj)
env.NoClean(lib)
does not give desired result - this preserves only final library file (lib.a) from clean. I've tried to preserve object files:
obj = env.Object(Sources)
env.NoClean(obj)
but this solves the problem only partially, because some object files compiled implicitly - the library code contains Qt code which processed by Qt meta-object compiler (MOC), therefore these object files do not included in 'obj' list.
Is there a way to prevent such third-part library rebuilding every time when the project rebuild carried out?
The SCons way of doing things would be to not call "scons -c", but only
scons
if you want to rebuild your project.
It is SCons main strength to get all the dependencies (implicit and explicit) right, even for an iterative rebuild where only a handful of files have changed. By using the "-c" option, like you may be used from other build tools like "make", you're shortcutting this feature and creating problems where there would be none usually.
I assume that you're using your "make clean; make all" approach because you haven't properly defined all the dependencies in your project yet. Please do that first, it will help your build in the long run.
And no, there is no method that will prevent "cleaning" for a whole folder and its subdirs.
Use env.Glob(), it will see files which SCons knows about but are not yet created when that logic is run.
I tried to install Parity (an Ethereum client) on my CHIP computer (similar to a Raspberry Pi with 4GB memory). I cloned the repository and ran
cargo build --release
After a while I noticed that about 40% of the memory was used and I stopped the installation process. There was only 20% used before, so now I want to clean all of this Rust stuff. How can I do that?
Cargo places all temporary build files into the target/ directory. Sometimes, if not already present, Cargo also creates a Cargo.lock file. The directory can be removed by executing:
cargo clean
Cargo also saves the package index and the source code of dependencies globally in ~/.cargo/registry/.