While trying to re-export rocket, I had the following problem:
rocket depends on macros to work correctly, but I know that since edition 2018 the use of
#[macro_use] extern crate rocket;
is not required anymore and in theory one can just write:
use rocket;
Somehow though, this doesn't work for the rocket crate.
I think this is the missing part to be able to re-export the rocket crate in a 'common' crate to my 'test' crate.
What am I missing? Thank you all in advance
Well, you still need the "absolute" path, in terms of modules, to the macro. For an instance, the #[get] attribute resides in rocket::get. Therefore, you would need use rocket::get.
Note: I have not actually tested out the code. But this is what theoretically should happen
Well, with use common::rocket::*; you can’t do rocket::build(), because you aren’t importing rocket itself. build() should work though…. Or you do use common::rocket;, then rocket::build() should work instead.
Full error messages help. Well, now I compiled it myself to get the error message anyways. Looks to me a lot like the get macro expands to some code involving rocket::… absolute paths, so maybe you can only use it in crates that directly depend on the rocket crate themself. (I.e. you’ll need the rocket dependency in the test/Cargo.toml.)
That’s actually quite a bunch of proc-macros that take this approach of using absolute paths and assuming the crate name. Which can lead to problems in cases like this, or e.g. in cases where a crate has been renamed. Not quite their fault, as AFAIK, there’s no good workaround that would work as well as $crate in a macro_rules macro works.