Thanks. My output was very similar, we both use the Swift 6 dev compiler it seems. Except that xcrun reports Xcode 15.4.
I still think that your setup works, because you run it in Sequoia VM with Xcode16, for some reason. Maybe the ESP-IDF library does not correctly choose the proper toolchain, even if the environment is set up. I wasn't able to get further since my last message.
Yeah, i suppose too.
I use VM with Xcode 16 for testing purpose because can't change OS on work laptop 
And for some reason I immediately assumed that ESP32 can only be programmed in new environment (OS + Xcode)
Little bit later i try to do so on Xcode 15.4 and Sonoma
% xcrun -f swiftc
/Applications/Xcode-15.4.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc
If you see this ^ then the TOOLCHAINS env var is not correctly set, or exported. You need to see a path pointing to the downloaded toolchain, not Xcode's toolchain. For example, I have the "Trunk Development" toolchain from Swift.org - Download Swift from July 29 installed:
% export TOOLCHAINS=org.swift.59202407291a
% xcrun -f swiftc
/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-07-29-a.xctoolchain/usr/bin/swiftc
Thanks! Having this information about the output of xcrun -f swiftc, I was able to set the proper toolchain with which I'm now able to build successfully.
I think I was encountering two separate issues in the end - the first being bad interaction of esp-idf with Python on the previous machine, but having the toolchains set properly there.
Second issue was my wrong approach of using the VSCode Swift extension which does not work yet with this setup and is unable to set the toolchain properly for VSCode and ESP-IDF VSCode extension.
Working only with the terminal esp-idf and having the toolchain exported in the environment like this now works.
Thanks all for the help!
I wonder if we could dig into that? Sounds like a gotcha that others can easily fall into too. I know that the Swift VSCode extension has a field in settings to specify a toolchain path. Are you saying the toolchain for IDF compilations is selected wrong even if this setting is set?
I'll gladly dig into the VSCode issues, since using its own build system would be a better experience for me personally than having to call the build from terminal.
The Swift VSCode extension allows you to choose the toolchain first, I always had the working one selected (as verified yesterday, it's the same one that worked in the terminal after properly exporting it)
The second step is to choose the developer directory. I have tried both, it had no effect on the result.
I also tried to export the toolchain in VSCode's terminal, like so:
% export TOOLCHAINS=org.swift.59202407241a
% swift --version
Apple Swift version 6.0-dev (LLVM 3c6e1d334961f5e, Swift 384d7f77a53d8a0)
but as we can see further below
% xcrun -f swiftc
/Applications/Xcode-15.4.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc
it will use the Xcode included toolchain/compiler if I understand it correctly.
If I then run the extension config command again and pick Xcode 16 beta in the second step, it still reports 15.4.0 in the xcrun -f swiftc output.
If I use the "Xcodes" app that I use to manage various Xcode versions and make the 16 beta active, VSCode terminal will then report:
% xcrun -f swiftc
/Applications/Xcode-16.0.0-Beta.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc
which points me to the direction of VSCode ignoring what's set in the extension and just uses the OS environment somehow.
With this setting, the issue with unknown bridging argument still persists in VSCode.
I got a similar error when trying to add a bridging header to the GitHub - anders0nmat/swift-embedded-pm project. The toolchain was correct but CMakeLists.txt is using swift build, so to pass the argument to swiftc I had to use:
-Xswiftc -import-bridging-header -Xswiftc ${CMAKE_CURRENT_LIST_DIR}/BridgingHeader.h
Thank you for this!
Even-though I wasn't able to get it build in VSCode using the adjusted parameters you provided (I put them in instead of the -import-bridging-header ${CMAKE_CURRENT_LIST_DIR}/BridgingHeader.h line), it pointed me in the right direction of adjusting the CMakeLists.txt file.
I'm not familiar with CMake at all, but I was able to get the build to finish by adding this to the file:
set(CMAKE_Swift_COMPILER "/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2024-07-24-a.xctoolchain/usr/bin/swiftc")
just before the set(CMAKE_Swift_COMPILER_WORKS YES) line.
It's by far not a universal solution, but at least I can use VSCode and its own build integration locally.
