The macro can only be built for the host architecture (since that's where it runs and that's what the SwiftSyntax dependency is built for). This works on Linux because the host architecture is always the same as the architecture for which we build Foundation. However, when building the Windows toolchain, Foundation is built for a variety of architectures that may include those that are not the same as the host. In the fullness of time, we need to ensure the macros only build for the host architecture (either by splitting it out into a separate, single CMake invocation or by providing the architecture to the cmake build to override for the macro target). But in the short term, to unblock merging the Foundation re-core, this disables the macro on Windows toolchain builds to keep the ball rolling. I'll revisit this once we get a toolchain going to see how we can add this back in. As it stands today, nothing in the toolchain relies on the macro (beyond unit tests) so this is ok to leave out for the interim.
The macro can only be built for the host architecture (since that's where it runs and that's what the SwiftSyntax dependency is built for). This works on Linux because the host architecture is always the same as the architecture for which we build Foundation. However, when building the Windows toolchain, Foundation is built for a variety of architectures that may include those that are not the same as the host. In the fullness of time, we need to ensure the macros only build for the host architecture (either by splitting it out into a separate, single CMake invocation or by providing the architecture to the cmake build to override for the macro target). But in the short term, to unblock merging the Foundation re-core, this disables the macro on Windows toolchain builds to keep the ball rolling. I'll revisit this once we get a toolchain going to see how we can add this back in. As it stands today, nothing in the toolchain relies on the macro (beyond unit tests) so this is ok to leave out for the interim.