Using a class from an external crate generate an extension conflict

[gcesars]

I am trying to organize the code and avoid a huge library with the entire game and data logic in a single file.

Let's say I have a crate_a with a class/resource and a crate_b that needs to refer to this class for any reason.

Just by adding use crate_a::class_name in the crate_b library, it stops working. However, it compiles and runs the game.

The error is: ERROR: Attempt to register extension class 'InputManager', which appears to be already registered.

My guess is that the class is being registered when the library_a is loaded and it is being registered again when library_b is loaded.

Is this a user error? How to avoid it?

[Bromeon]

Can you elaborate your crate setup?

Are the two crates both cdylib? Dependencies?

[gcesars]

For sure:

crate_a cargo.toml:

[package]
name = "game"     # Part of dynamic library name; we use {YourCrate} placeholder.
version = "0.1.0" # You can leave version and edition as-is for now.
edition = "2024"

[lib]
crate-type = ["cdylib", "lib"] # Compile this crate to a dynamic C library.

[dependencies]
godot = { workspace = true }

crate_b cargo.tml:

[package]
name = "level"    # Part of dynamic library name; we use {YourCrate} placeholder.
version = "0.1.0" # You can leave version and edition as-is for now.
edition = "2024"

[lib]
crate-type = ["cdylib", "lib"] # Compile this crate to a dynamic C library.

[dependencies]
godot = { workspace = true }
game = { version = "0.1.0", path = "../game" }

I need to include "lib" in the crate type. Otherwise, crate_a cannot be referred to in crate_b. I think this might be the issue.

Both crates have one declared class with some #[extern] fields.

Without crate_b referring crate_a in use statement, I can see both classes in the editor and the game logic works.

[Bromeon]

I need to include "lib" in the crate type. Otherwise, crate_a cannot be referred to in crate_b. I think this might be the issue.

Yes, indeed. There are some general problems with this setup in Rust, see e.g. "Problems" section in #986.

But you'll find most information + some trade-offs in #951. In short, dependencies between libraries is a workflow that's not properly supported yet, and there are probably a few things we need to do to avoid errors like these.

[gcesars]

Thanks.
For now, I'm just exploring and learning. Having all logic in a single library isn't a big deal.
It is a problem in the long term, though. The compilation time will increase, and patching will become more complex.
I hope the team can figure it out eventually.
Apologies for not being capable of contributing to the solution.

[Bromeon]

All good, no worries! I agree it's an important topic 🙂

I'll close this in favor of #951 to keep things in one place, but in case you have more input on this topic in the future, feel free to comment there directly!