Can we treat native folder as workspace crate rather than a library crate?

[temeddix]

Currently, the folder structure goes like this:

• project_root
  • windows
  • linux
  • macos
  • ...
  • native (Library crate)
    • Cargo.toml ([lib])
    • Cargo.lock
    • src
      • api.rs
      • lib.rs

However, it would be so nice if the folder structure can be like this:

• project_root
  • windows
  • linux
  • macos
  • ...
  • native (Workspace crate)
    • Cargo.toml ([workspace])
    • Cargo.lock
    • first_crate (Library crate)
      • Cargo.toml ([lib])
      • Cargo.lock
      • src
        • api.rs
        • lib.rs
    • second_crate (Library crate)
      • Cargo.toml ([lib])
      • Cargo.lock
      • src
        • api.rs
        • lib.rs
    • third_crate (Library crate)
      • Cargo.toml ([lib])
      • Cargo.lock
      • src
        • api.rs
        • lib.rs

This is basically because for bigger projects, single Rust crate is not enough. Dynamic library files(.dll, .so) are usually multiple instead of being just one in actual softwares.

Take a look at https://github.com/AppFlowy-IO/AppFlowy. Although this project doesn't rely on Flutter Rust Bridge, they do make use of multiple Rust crates in their own way.

I've already applied this idea to our repository https://github.com/cunarist/app-template and is working well. I only modified CMake files for Windows and Linux and created some Python scripts in automate folder to do this. corrosion CMake package already supports importing and linking multiple Rust crates. I believe this transition would be possible if the maintaner decides to do so.

I thought about making a pull request but since this involves changing contents in CMake files, FRB Dart package, documentations and so on, I wanted to ask if this idea would be allowed to go into master.

[fzyzcjy]

IMHO this should work well, given that frb itself is only a thin code generator and runtime, and never requires how that folder looks like. I also use multi crates in my own app.

However, I am wondering whether changing the template it good or not, because it makes it a bit more complicated and new users may need more time to understand. Surely, they get more powerful template as well :)

/cc @Desdaemon who wrote the helpful templates - what do you think?

[temeddix]

Also I was curious how this repository https://github.com/Desdaemon/flutter_rust_bridge_template is related to this one.

According to the official docs, we are encouraged to start a new project from this template, but since the author was different I got confused. It's Desdaemon/flutter_rust_bridge_template, not fzyzcjy/flutter_rust_bridge_template.

Now I see that you two are cooperating, but I just wanted to say that it was a little misleading :)

[fzyzcjy]

Yes that template is written by @Desdaemon , who contributed a lot to this repo (see README for a detailed list) :)

Btw @Desdaemon - do you think we should somehow explain it a bit more to avoid possible confusion?

[Desdaemon]

Agreed, people may be confusing the template repo as part of FRB itself. Perhaps a note in the docs is needed?

[fzyzcjy]

Done