How to work around the fact that clearly there is file bindings_included yet system either doesn't see it (when I use create instead of super) or tells me that I use super too many times even though I only have one super keyword
How to tell the system that the main is in cdemodc_c and use this main not the main functin from main file that is used by the lib
error[E0432]: unresolved import `crate::bindings_included`
--> src/cdemodc_c.rs:1:12
|
1 | use crate::bindings_included::*;
| ^^^^^^^^^^^^^^^^^ could not find `bindings_included` in the crate root
I see now that you listed it as a binary.
Then it may not be considered part of the library crate and you need to specify the crate's explicit name: my_app_rs::.
In any case, if this is a binary module, you should not put it into the library crate's src/ dir, but into a separate bin/ dir.
Hi, this solved the issue.
Thanks
So to summarize:
Adding pub to mod bindings_included.rs was all that was required.
And that is fine.
But still, what about the bin/ folder? Is it still required? Tbh, the error messages were confusing at best.
I believe using my_app_rs:: is also required for this to work. Basically you need lib.rs to declare (with mod) and make visible (with pub) the bindings_included module. Other binary crates will then see the lib.rs as another crate named my_app_rs which you can import from (but like other third party crates you can only import public stuff!)
The bin/ folder is just a convention, it is not needed, but generally appreciated when people look at your code.
I think working with multiple crates in a single package is the confusing part. You normally would expect all the files in src to be in the same crate and thus "know" each others, but actually they are in different crates (each file in [[bin]] is its own binary crate, plus lib.rs is a separate library crate).
Add to this the fact that suggestions about changes in other crates are usually avoided because it would be very confusing to suggest a user to make changes in a third party crate.