Uh, trying to build with that ninja command gives me fun errors like <unknown>:0: error: module 'Swift' cannot be imported in embedded Swift mode. That seems strange considering it was building fine just now.
Swift has some kind of comfort zone. If you use SPM and don't do cross-platform compilation, everything works fine (as I just said, Xcode, VSCode, Zed all work fine). But if you don't want to use SPM, or want to compile cross-platform, it's much more difficult.
I tried to compile an SPM project for iOS on macOS before, and tried many solutions, including setting parameters for sourcekit-lsp, but none of them worked (as shown in your picture, image: <<error type>>). In the end, I fell back to Xcode (with xcode-build-server) to solve it.
This is the type of thing I've found. A lot of it actually is in the C++ context, but my C/C++ compilers have historically been some flavor of gcc, so I'm not deeply familiar with using them with C/C++ either!
Honestly, in your place I might consider going ahead and using a package in C++ compatibility mode, moving it over piece by piece. You could then use the swiftpm section of the config.json to do some of the set up. That might go easier than wrestling with the ninja and cmake generators.
Hunh about the Ninja error b/c I did use Ninja with with embedded for a C/Swift embedded combo build... but that build file didn't use the CMake Swift mode, it used the custom_command call
I cribbed off the pico_w example in the embedded examples repo.
For what it's worth I did all the folders in that repo essentially just ignoring all the red squigglies. Why I'm doing all this myself. Going back and applying what I've learned to that is a goal.
I can't use C++ interoperability as the C++ code is using C++ modules which Apple Clang disables for whatever reason, and if it didn't Swift does not support them.
Core works correctly as it has no dependencies, and the ones that exist use conditional compilation. Files correctly see each other, so for example Drawable.swift has access to Float.normalize from Math.swift and the LSP is able to suggest those methods and check errors.
Engine does not work, as files there depend on Core. import Core fails with an error SourceKit: No such module 'Core'. This is confusing because both CMake and Xcode through Package.swift resolve the modules perfectly fine, though Xcode is completely broken with the toolchain in other ways.
OpenGL.swift is the weirdest file. It has a @preconcurrency import GLAD which comes from a module map. What's strange about it is that it does work, in that I can hover over types like GLenum and I get a correct tooltip, but there is no error checking or completion happening at all.
Sorry, though you'd switched to trying to make a Package.swift work with C++ interop and it wouldn't swift build, which isn't anything you said. Assumptions on my part.
Interestingly, when I copied a file into a directory that is not part of any module, Xcode started showing completions — not errors though.
And in proper files it shows errors but not completions
It shouldn't even be able to import these in a random untracked file?
I wonder what the AI is trying to do with these properties
I managed to get it working, though only in VSCode (which I hate) and not without a Package.swift. Which is a problem because unlike CMake the Swift build system can't handle a module-less main file.
Xcode is still broken and so is Zed, but the latter doesn't surprise me, it never worked with Swift modules in the past.
For some reason the package did not want to recognize a modulemap for SDL3 with an absolute path. I had to copy all the SDL3 headers into the modulemap directory and mass rename their own includes to be relative, after which it now started working!!!
The compiler can finally compile to more than 2 platforms, there is a less janky build system thanks to CMake support, but the LSP is even worse than before
What is going on? Why is the language server so janky, can Apple not afford development?
I am very much confused by what the real problem is. There is the Xcode project format, the Swift Package Manager (SPM) format, and there is cmake. Those are separate project formats to begin with. And yes, a Swift file without a “module” is not a thing with SPM. Then you talk about mixing C++ with Swift, which is a special case.
I think you have special requirements in your project, in those “edge” cases so to speak a minor weakness in your project definition might lead to different result using different tools. I find it difficult to start with a general judgement about Xcode, you maybe should present a complete example so others can help. The output could of course be that Xcode is doing something wrong or is missing some features.
I did not mention Xcode projects but rather opening a Package.swift project in Xcode. And the only reason I am using a Package.swift in a Cmake project in the first place is because, as I said, sourcekit-lsp does not like my compile_commands.json and ignores it.
I did not mention mixing C++ with Swift, it was suggested to me, and it is not something I am doing in this case.
The issue is that there is no IDE or code editor which seems to work for my project.
My judgment of Xcode comes from the fact that despite having a "Toolchains" menu using anything but the one built in breaks something every month or two. This happens regularly.
Thanks for the tip. I had done some ESP32 Embedded Swift development and didn't realize this was preventing me from using the normal Swift Package tools swift package init even after selecting the "build setting" in Xcode or using xcode-select
That means there’s a bug — please report it! It’s possible that this assertion failure is preventing some other part of the compiler from giving you a more understandable error about what it thinks is wrong in your code.
if you are using nightly toolchains, you will run into a lot of compiler crashes. not just when compiling, but also when doing source edits against sourcekit-lsp.
if you are really dead set on using nightlies, you can compile a custom toolchain with noassert configuration, although there is a high likelihood that the assertions removed are meaningful and you could end up with miscompiled code. (the release toolchains are built in this configuration)
