Disable dependency implementation compilation when compiling

[spice monolith]

1. I have a shared library crate (plugin) that depends on application crate (app).
2. The shared library is intended to be loaded into app dynamically (using libloading)
3. The shared library must be able to call any function from app (and also operate with the same memory).

The problems now is that plugin crate is compiling its own binary implementation based on its app dependency.
Therefore calling a method like app::something actually calls a local binary ver from the shared library .so...

I want to make compiler not to compile these app's implementations inside the plugin completely.

Disable dependency implementation compilation when compiling

[shadow wigeon]

You cannot do this.

Runtime-loaded components of any stripe, whether dll or wasm module or lua script or foreign process, can only communicate over a laid-out-in-advance interface made for that purpose, whether C-abi functions or gRPC endpoints or etc

The universe of things that automatically understand the Cargo crate tree exists entirely within only one invocation of cargo build. The only form of plugin system that can automatically interop with the dependency tree is one where the plugins are ordinary Rust lib packages compiled into the project, with specifying the plugin list being done by modifying Cargo.toml to link them before compiling it fresh. Everything else is going to involve defining a interface boundary in a language-mostly-neutral protocol.

Independently of that, a dll being able to import functions from its host is platform-specific. So you doubly can't do that in particular. Usually instead a vtable containing all the 'imported' functions is injected into an init function for the dll.

[spice monolith]

uhm is that what I am doing now?

I currently found a way to define definitions like external "Rust" ... instead of implementations for the core code if the flag def is set.
So the plugins depend on the definition code and the core app is compiled with the implementations..

I guess there should be a way to do it better.. because current way is wrapped around buggy macroses... who happen to lose rust-analyzer integration.