I think macro targets should work exactly like build scripts, except they are compiled as a proc macro library instead of an executable, and exposed as a dependency to the main targets instead of run before building the targets.
To be concrete about what I mean:
- Each package can have exactly one macros target, not many. There is a default path to find it at, which can be overriden with a
packages.macroskeys. - These packages are exposed to the library and binary targets as a dependency under a standard name (probably
macros::). Users can rexport from this crate to expose them to downstream users. No magic re-export is done. - The macros target either has access to build-dependencies or to a new macros-dependencies section which functions from a resolution perspective just like build-dependencies except that one is exposed to the build script and one is exposed to the macros.
By making macros function just like build scripts except exposed as a library instead of executed before building, this is a reasonably scoped feature to add. But adding a new variadic target with its own configuration, sets of dependencies, etc, and adding new magic paths that have to be coordinated between cargo and rustc, greatly increase the scope of this feature for implementation & design. We should start with the easy version and can consider adding these bells and whistles later.