I have what is conceptually a single crate that currently works like so:
- a bunch of proc macros that actually do the work the crate's designed for. The user's code invokes these.
- a bunch of "ordinary" items, which client code has to be able to see because...
- the code that the macros generate refers to those items.
- a bunch of tests of the macros
My current setup is that the ordinary items (A) and macros (B) live in two different crates, crate A re-exports the macros from B, and the testing code lives inside crate A. The issue starts with Crate A being marked as a workspace, but doesn't have B as a
member for reasons I'll get to in a moment, instead having B as an "ordinary" dependency defined by its path in a subdirectory. Trying to have B as a workspace member doesn't work because (I think) it means A can't re-export the macros from B publicly, but I might have misunderstood that. As is, the testing code falls over because, AFAICT, the generated references to
::A don't resolve from within crate A correctly. (And obviously can't refer to
crate:: because in normal use, it won't be)
On top of the tests not working, this is not a great setup because I want to be able to package this whole mess on crates.io, ideally as a single crate rather than having to separately upload the macros and keep the two in sync. AIUI, this is impossible if I have path dependencies.
Another thought was to have the tests in a third crate (C), but I didn't know if it was possible to have that crate as a workspace member and have it depend "up" to B, since B is the conceptually most important. I also considered splitting the three so that they are all equal packages in a virtual workspace, but I don't really know if that'll work either.
Is there any way to make this work without running into inconveniences somewhere?
Because AIUI, a proc-macro crate can only expose macros, and no other kind of item ↩︎