Generating as #[test] causes rebuild

[d2weber]

#76 adds qt bindings generation. To use them via deltachat-cffi one has to do both

• cargo build -p deltachat_cffi
• cargo test deltachat-jsonrpc

Because one is build and the other test everything including all deps gets recompiled from scratch for each. Can we maybe not generate #[test]s but just functions and the yerpc-consumer can decide what to do with them? Maybe we could ditch all the arguments on the rpc proc-macro and instead generate one function which can do anything, maybe even set up to be used in a binary with a cli?

[link2xt]

Maybe the correct way is to create another crate for bindings, then generate the bindings in build.rs using a function derived by yerpc. Or just create a binary crate that calls the binding generator from main.

[d2weber]

Maybe the correct way is to create another crate for bindings, then generate the bindings in build.rs using a function derived by yerpc.

Yes I think you are right, this is the best way. The advantage of using build.rs instead of a binary crate is that cross compilation should just work. If it was a binary crate that binary can't run on the host arch.
In deltatouchs CI we use clickable which cross compiles so I sketched out a draft to generate bindings in a separate crates build.rs in my draft PR chatmail/core#8330 (to build successfully with clickable I had to set HOST_CC manually). Instead of creating tests, #[rpc()] generates pub fn generate_ts_bindings() and pub fn generate_qt_bindings().

I think it would be better to put that in a separate PR and add qt bindings later. Maybe we could adjust the generate_*_bindings fns to accept the path, so that #rpc(..) wouldn't take parameters anymore. If you think that sounds ok I can create a PR for that.

[Frando]

Yee, build.rs sounds like the best approach to me too. I inherited the test thing from another library when I first wrote yerpc and never really liked it. Let's change it.