-
Notifications
You must be signed in to change notification settings - Fork 240
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
Support fetching metadata from crate #1660
Comments
From the linked issue, I like the idea that you can point Subxt at the WASM runtime and have it extract and use the metadata from it. Then, I think we could have:
I'd prefer to avoid the subxt macro having to know or care anything about the structure of the |
I mean what I proposed does not require to know the structure of the repo? Only need to know how |
Since we need to extract metadata from the runtime WASM regardless, adding I do still think that building the WASM makes more sense as a separate step though, as there may in the future (if not already somewhere) different ways to configure the build for some runtime (eg via crate features or env vars), and so doing it separately means that Subxt doesn't also need to bake in any additional things to handle setting this sort of stuff.
Ah yeah, indeed, I was thinking down the wrong line when I wrote this! I guess it would just run a |
I'd also prefer to keep |
What need? Can you clarify what you mean by this. |
My thought process as follows:
So the line of thinking I followed is that for development it's better to leave the decision whether or not to rebuild the package to the user of the library instead of baking in any assumptions inside the macro logic/rebuilding on every new change But I can add a commit with package building tomorrow if need be Edit: Yeah, baking in build process can be fine for one shot stuff or dependencies, but I'd leave it as providing "runtime_crate_name" & "wasm_file_path" to not bake in any assumption on the location of produced artifacts. Ie
|
Yeah that should work. However, we still need to trigger the build and ensure that the consuming crate it build after the wasm is build. |
I think we still need to allow to set the |
Okay, i've tried implementing the build step inside the macro and unfortunately it will deadlock due to the build lock on the target folder. commented out code inside the commit So no
even if it was possible to call Middle ground proposalsupport |
I'm still of the opinion that supporting |
The
subxt
macro currently supports to fetch the metadata from the filesystem or from some RPC node. However, for the future zombienet rust tests, it would be nice to also specify a crate.So, something like this:
The
crate_name
would be required to be path of the same workspace.wasm_file_name
should be optional and if not given, it should be guessed based on the build output. If there is more than one wasm file, the macro should complain.features
is also optional and just activates some feature at compile time.https://github.com/paritytech/polkadot-sdk/tree/85f0edae1d6c461081f42fcabd13e547e5a5b683/substrate/.maintain/build-only-wasm.sh could be helpful here.
The text was updated successfully, but these errors were encountered: