You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this case we indirectly export near_sdk of a correct version, but running cargo near build will fail finding near_sdk.
The lookup code currently is looking only on the top-level (direct dependencies). This check itself allows us to prevent usage of incorrect version of near_sdk, and not to get sigfault if dependencies are non-consistent.
What I suggest to do is:
Check the resolve struct of crate generated by cargo_metadata
Find all near_sdk in dependency graph no matter them being direct or indirect
Check them all being suitable, if one of them isn't there is a change of indirect usage in the bindgen crate that may bring non-consistency.
The current near_sdk version check, is not flexible and vulnerable, if I will implement to the following scheme:
I will avoid check to panic at ABI generation and will get the non-consistent effect.
Another solution that may be combined with the previous one is to add a --no-sdk-check flag
cargo near build --no-sdk-check
This will allow for people that know what they are doing to avoid forking and patching this util if there will be any unmentioned cases for compilation.
The text was updated successfully, but these errors were encountered:
BadConfig
changed the title
near-sdk version check for indirect dependencies
add near-sdk version check for indirect dependencies
Nov 14, 2022
Let's assume we have the following structure of dependency tree:
In this case we indirectly export
near_sdk
of a correct version, but runningcargo near build
will fail finding near_sdk.The lookup code currently is looking only on the top-level (direct dependencies). This check itself allows us to prevent usage of incorrect version of
near_sdk
, and not to get sigfault if dependencies are non-consistent.What I suggest to do is:
resolve
struct of crate generated bycargo_metadata
near_sdk
in dependency graph no matter them being direct or indirectThe current
near_sdk
version check, is not flexible and vulnerable, if I will implement to the following scheme:I will avoid check to panic at ABI generation and will get the non-consistent effect.
Another solution that may be combined with the previous one is to add a
--no-sdk-check
flagThis will allow for people that know what they are doing to avoid forking and patching this util if there will be any unmentioned cases for compilation.
The text was updated successfully, but these errors were encountered: