Support SwiftDriver output file maps from Xcode 16.3+

[qeude]

Summary

Make xcodemake understand the Swift build output produced by Xcode 16.3+.

Newer Xcode versions often describe Swift compilation through SwiftDriver and an -output-file-map JSON file, rather than only through the older SwiftCompile lines. Without parsing this format, xcodemake can miss Swift files when generating the Makefile.

This adds support for that format, so editing a Swift file is more likely to trigger the right incremental make rebuild instead of requiring xcodebuild to recapture the project.

Details

• Parse SwiftDriver compiler entries.
• Read and decode the -output-file-map JSON with JSON::PP.
• Generate Swift object rules from output file map entries.
• Reuse the same Swift rule writer for both SwiftDriver and legacy SwiftCompile.
• Harden path escaping for Swift files and object files, including paths with spaces.
• Ignore informational SwiftCompile log entries that do not include a compiler invocation.
• Keep per-object rules for compatibility with macOS GNU Make 3.81.

Validation

• perl -c xcodemake
• Generated a Makefile from a real Xcode 26.4 build log containing SwiftDriver entries.
• Verified generation produced no stderr warnings.
• Verified /usr/bin/make -n -f .xcodemake/Makefile reported no overriding-target or missing-target diagnostics.
• Verified Swift paths containing spaces are escaped correctly in both Makefile rules and touch commands.

[johnno1962]

Does adding build setting EMIT_FRONTEND_COMMAND_LINES=YES in the project work to get the old format?

[qeude]

I believe so. With EMIT_FRONTEND_COMMAND_LINES=YES, Xcode should emit the old frontend command lines that the existing SwiftCompile parser expects.

This PR is useful for the default Xcode 16.3+ behavior, where those frontend command lines are not emitted unless the project opts into that setting. In that case, SwiftDriver plus -output-file-map is the available source of truth for generating the Swift rules.

[johnno1962]

Rather than practically rewriting the script which is risky, couldn't we just add EMIT_FRONTEND_COMMAND_LINES=YES to the xcodebuild invocation?

[qeude]

Yes, I think that would probably work and would be a much smaller patch.

I see the tradeoff as short-term compatibility vs supporting the new default format: EMIT_FRONTEND_COMMAND_LINES=YES opts back into the old log output, while this PR handles the SwiftDriver output Xcode 16.3+ emits by default.

Happy to switch to the smaller approach if you prefer.

[johnno1962]

At this stage I'll opt for the smaller incremental approach please. You never know what Xcode 27 will have in store. It's good you pointed this out though. I wonder how many people gave up?

[qeude]

Okay, I'll check later to make a simpler approach, not sure how much people gave up, on my side it's somehow working with or without that change using recent version of Xcode. I took inspiration on that fork which is from the main maintainer of XcodeBuildMCP just to use modern technologies and make it useful for most people

[johnno1962]

Man, everybody's coding Perl now! I'd still opt for the smaller change since that option resurfaces the old behaviour. The trick is going to be working out where on the command line to insert the build setting.

[johnno1962]

I've invited you as a collaborator as your knowledge of this script as just overtaken mine though I'd still like to review PRs before they are merged for now as "I know some things about Apple build systems". BTW, another user is vibing up an InjectionMCP server if you're interested: johnno1962/InjectionNext#133.

[qeude]

Sure, will check 😁