'swift' is the interpreter. 'swift -frontend' is an internal, unstable interface that is not suitable for calling from anywhere else. And CMake's "file-at-a-time" approach is not compatible with Swift's implicit cross-file visibility—that's why it has its own dependency analysis system.

(Hi, Eric. Doug showed me that you and others were starting to work on CMake support for Swift, and I've been meaning to chime in on your thread to help you out. Feel free to pull me into a discussion there.)

Comment by Eric Wing (JIRA)

Drat. I've been cross-verifying with what Xcode does.
The file at a time thing seemed to work as long as I passed the list of all Swift files, which was doable with minor changes to CMake internals.

This is what the invocation looks like roughly right now:
swift -frontend -c -primary-file
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/OtherSwift.swift
/Volumes/DataPartition/Users/ewing/Source/CodeTest/CMakeSwiftBasic/main.swift
-emit-module -module-name MyTarget -o
CMakeFiles/MyApp.dir/OtherSwift.o

Changes to use swiftc look like it will require more drastic changes to CMake internals. (I'm not an official (skilled) CMake maintainer and am doing this on my own time, so this could effectively turn into something that kills this endeavor.)

Yeah, that's debug output more than a supported interface. You could get the commands swiftc would actually run, but that still won't do a real job tracking what does and doesn't need to be recompiled. (And that skips the merging of the individual module files into a single module at the end, which you need to do for a library or proper debugging.)