Would it ever be possible to have a proc Macro definition inside of a regular crate? I keep running into the case where I want to have a compile-time and run-time version of an API, which share virtually all the same internal code with different interfaces, and currently to achieve that you have to split your single crate into three-four crates, which becomes much more of a hassle to maintain and publish on crates.io.
I understand why it wouldn’t be possible to both define a proc macro and use it in the same crate, but I think allowing just the definition would still be a huge quality of life improvement for me.
Seems to me like the problems of "compiling multiple different crates from one set of source files" remain the same when when the crate doesnt use its "own" proc_macro.
and AFAIK that is what makes mixing proc_macro and lib code so hard.
That's true, and to be honest I don't even want a proc macro. I just want to be able to perform certain operations at compile time, such as reading and parsing files from a directory, and currently proc macros are the only way I know to do that.
I might not understand the problem fully but what about
@marmeladema I want to expose a compile time API to users, a build.rs only works inside my crate. To pick a simple example I want to have
It wouldn't work for that particular case, but some such things could be done with
const fn. For those that can't, though, a proc macro seems right, and it would be nice to be able to provide one from the same crate.
Thinking on this more I was thinking my problem is more with Cargo than rustc and having to turn my project into a cargo workspace just to support macros, I was thinking what if instead of having to set
proc-macro = true, cargo had a macro target similar to bin, that could act as the place to declare the macros that exported as part of your library. E.g.
[[macros]] name = “derive” path = “macros/derive.rs”
This could also provide the benefit of being usable in your crate if it doesn’t depend on it. So it’s easier to have macros as a private implementation detail, which I have wanted more recently.
Either way I think I’ll write a post about it on internals since it’s bigger in scope.