Correct me if I'm wrong, but it seems to me that Swift Macros run hand in hand with SwiftPM. Now, I have a project whose cross-platform build process relies heavily on CMake, so I'm evaluating a different option than making macros work in CMake –if it's ever been a thing.
Xcode has a "Refactor > Inline Macro" menu that does what I need, which is running the macro on the target entity and producing the actual code. Well, I wonder if there's a way to do this from the command line, as in a codegen-like behavior. I don't need the generated code to be 100% in sync with the original source. I'm okay with doing it manually from time to time, but I need it to be easy to automate, as in "inline all the macros that you find in the codebase".
I haven't found a viable solution so far. Am I hopeless?
SwiftPM builds macro implementations and passes them to the compiler so that they can be used in expansions, but this is possible from (and the responsibility of) any build system. Ultimately, you need to get the executable built and pass it to the compiler using the -load-plugin-executable <executable path>#<comma-delimited list of module names> flag.
For example, Bazel supports it by letting a swift_library target (which represent a module) depend on a swift_compiler_plugin target (which represents the macro).
I don't have much experience with CMake, so I'll defer to the owners of the Swift integration to speak on how macros are supported today. But you should never be required to manually expand the macros to get your code compiling.
While swift-java performs transpilation from source code, in cases where the code uses macros that generate members (such as the `@MemberwiseInit` macro), I want to pass the post-expansion source code as the input to the transpiler.
Can you explain what you mean @omochimetaru ? You mean that swift-java when applied to some code using macros will miss out on the added members? Yeah that’s true, we could instead use the generated swift interfaces if necessary — please file issues with your specific problem on the swift java repository.
Nitpicks: swift-java is not a transpiler, just a source generator creating wrappers/bindings
I believe this issue is not limited to swift-java, but is a complex matter that requires considering the best approach for the interface design of the entire toolchain, including SwiftPM and the compiler.
However, since I think the starting point of my motivation is easy to understand, I have opened an issue in the swift-java repository.
Oh, I'm sorry. I forgot to leave a comment.
Calling it a "transpiler" was incorrect.
That term could lead to the misunderstanding that even the implementation body is being converted to Java.
I have corrected it to be called "bridging code" instead.
FYI, I managed to integrate macros in my CMake workflow. Now it's a matter of some polish before I push it to the public repo, I'll let you know here in case you're interested.
I've just updated my project with a CMakeLists.txt that showcases how to build a minimal Swift executable using Swift Macros. Worth noting that my macros also depend on a C target, which completes the picture. I hope this helps others in my situation.
Thanks @allevato for the right pointer. It's been a good opportunity to understand how macros really work under the hood.