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
I would want the IDL emitted for crate_b to have all the type i+ account nformation for foo.
Currently this information is only available to crate_a, and so crate_b would either have to re-define crate_a::MyAccountsA in its own src/lib.rs or use all the accounts in flattened form, instead of composing crate_a::MyAccountsA directly.
Solution
To achieve this, we can have the various macros generate trait implementations providing IDL/type information. Additionally, we probably need to add some type of build.rs file that calls these generated traits to output the IDL, instead of just parsing the program's file directly, as we do now.
The build steps might be organized into
Walk entire crate to find IDL types.
Generate idl.rs file, invoking the traits on the IDL types.
Emit IDL by running the build.rs file
The text was updated successfully, but these errors were encountered:
Motivation
Suppose I had a field
foo
of typecrate_a::MyAccountsA
that is embedded intocrate_b::MyAccountsB
as follows.I would want the IDL emitted for
crate_b
to have all the type i+ account nformation forfoo
.Currently this information is only available to
crate_a
, and socrate_b
would either have to re-definecrate_a::MyAccountsA
in its ownsrc/lib.rs
or use all the accounts in flattened form, instead of composingcrate_a::MyAccountsA
directly.Solution
To achieve this, we can have the various macros generate trait implementations providing IDL/type information. Additionally, we probably need to add some type of
build.rs
file that calls these generated traits to output the IDL, instead of just parsing the program's file directly, as we do now.The build steps might be organized into
The text was updated successfully, but these errors were encountered: