Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dependency: hex-literal fails to build #9

Closed
bddap opened this issue Jul 16, 2019 · 7 comments

Comments

@bddap
Copy link
Contributor

@bddap bddap commented Jul 16, 2019

cd substrate-node-template
./scripts/build.sh

results in

error: proc-macro derive panicked
  --> /Users/a/.cargo/registry/src/github.com-1ecc6299db9ec823/hex-literal-0.1.3/src/lib.rs:38:1
   |
38 | / proc_macro_expr_decl! {
39 | |     /// Macro for converting hex string to byte array at compile time
40 | |     hex! => hex_impl
41 | | }
   | |_^
   |
   = help: message: assertion failed: `(left == right)`
             left: `Some("#[allow(unused,")`,
            right: `Some("#[allow(unused")`
   = note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
@bddap

This comment has been minimized.

Copy link
Contributor Author

@bddap bddap commented Jul 16, 2019

hex-literal 0.1.3 is the offending version. Updating to 0.1.4 remedies the issue.

Simply updating ./substrate-node-template/runtime/Cargo.lock fixes things by letting hex-literal update to 0.1.4.

cd substrate-node-template
rm runtime/Cargo.lock
./scripts/build.sh
@soc1c

This comment has been minimized.

Copy link

@soc1c soc1c commented Jul 17, 2019

getting the same, bumping hex-literal to 0.1.4 works for me too. thanks @bddap

@soc1c

This comment has been minimized.

Copy link

@soc1c soc1c commented Jul 17, 2019

shawntabrizi added a commit that referenced this issue Jul 17, 2019
update wasm Cargo.lock to fix #9
@kaichaosun

This comment has been minimized.

Copy link

@kaichaosun kaichaosun commented Jul 25, 2019

If using substrate-node-new command to create new node, delete runtime/wasm/Cargo.lock, then rebuild with ./scripts/build.sh can fix this issue.

@shawntabrizi

This comment has been minimized.

Copy link
Member

@shawntabrizi shawntabrizi commented Jul 25, 2019

@kaichaosun So we should update the v1.0 branch of substrate with fix then?

@kaichaosun

This comment has been minimized.

Copy link

@kaichaosun kaichaosun commented Jul 26, 2019

There are a few options in mind, and I noticed a few discussions in the document channel:

Option 1: Update the v1.0 of Substrate as you mentioned, but the substrate-up actually uses this link to download template node, needs to figure out what's the process to release & test the change:
http://releases.parity.io/substrate/x86_64-debian:stretch/latest-v1.0/substrate-node-template.tar.gz

Option 2: Use substrate-package as a standard way to create template node

Option 3: Keep using substrate-up scripts, but move node-template out of substrate codebase and have its own release process.

FYI: Option 1 is still the default option during my current work, there's a plan to update v1.0 of Substrate after knowing enough about the release process. @shawntabrizi

@shawntabrizi

This comment has been minimized.

Copy link
Member

@shawntabrizi shawntabrizi commented Jul 26, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.