Duplicating classes generated when use flutter_rust_bridge_codegen with cross dependency

[Xudiwen]

Greetings and thanks for answering my previous issue.

First, I have rust crate rust-library and a corresponding flutter library flutter-library.
Some FFIs between rust-library and flutter-library are generated by flutter_rust_bridge_codegen.
For example, in rust-library:

#[frb(opaque)]
pub struct Data {
}

#[frb(sync)]
pub fn hello(data: Data) {
}

In flutter-library:

abstract class Data implements RustOpaqueInterface {}

void hello({required Data data}) =>
    RustLib.instance.api.crateHello(data: data);

Then, I add a flutter-app depends on flutter-library, with a rust crate rust-app depends on rust-library.
flutter-app needs to add FFIs with rust-app, which would use structs in both rust-app and rust-library.
However, if I use flutter_rust_bridge_codegen to generate FFIs for rust-app depending on rust-library, some structs in rust-library would be generated again.

It's like in rust-app:

use rust_library::Data;

#[frb(sync)]
pub fn hello1(data: Data) {
}

In flutter-app:

abstract class Data implements RustOpaqueInterface {}

void hello1({required Data data}) =>
    RustLib.instance.api.crateHello1(data: data);

Obviously the two Data classes are duplicating.

Beyond this, there are also some issues about handlers and library loading.

What should I do with this cross-dependency?
It seems flutter_rust_bridge_codegen should be used only once in a project.
Thus I should not use FFI in flutter-library?

[Xudiwen]

Another question about #[derive(Default)] and #[frb(ignore)]:
To ignore the Default trait, I need to manually impl it now. How can I just ignore it with using #[derive(Default)]?

[fzyzcjy]

You are welcome!

Yes it would be easier if there is only one single Rust crate. Maybe there can be a single rust-everything crate, and two flutter libs can use it.

To ignore the Default trait

Btw curious why do you want to ignore it?

How can I just ignore it with using #[derive(Default)]?

IIRC there is no such feature now, but feel free to PR for it! The workaround may be e.g. do not ignore it (and just do not use it)

[Xudiwen]

Btw curious why do you want to ignore it?

The #[derive(Default)] trait cannot be annotated so it will generate an async constructor. I'd rather provide no async function on some data type.

Maybe there can be a single rust-everything crate, and two flutter libs can use it.

The problem is that I want to declare FFI methods in a flutter library, which needs some generated dart code; and then the flutter app depends on the library cannot do generating again.

[fzyzcjy]

The #[derive(Default)] trait cannot be annotated so it will generate an async constructor. I'd rather provide no async function on some data type.

I see. Not sure but if that function is never touched or used, I wonder maybe it will not cause harm

The problem is that I want to declare FFI methods in a flutter library, which needs some generated dart code; and then the flutter app depends on the library cannot do generating again.

Hmm, then is it possible to make the flutter lib do everything related to frb, and the flutter app do nothing about frb