Use development toolchain of Swift

[jeanbarrossilva]

(This was tried in #44, but turned out to be an unsuccessful attempt.)

Differentiation is required for implementing fields (#40), but the automatic differentiation framework of Swift is available only in development versions of the toolchain. Ideally, configuration of the GitHub workflow would be as straightforward as

1. downloading Swiftly, the official manager of Swift toolchains;
2. installing the development toolchain; and
3. specifying such toolchain to xcodebuild and swift run,

but, as of the present date, development toolchains do not include the GNU linker (ld), which is necessary for compiling Swift sources. This means that only following the above steps would result in the workflow failing.

The solution, which I caringly deem a workaround, is to simply¹ create a symlink to the ld of the Xcode-bundled toolchain in the toolchain used by Deus. This can be done manually, but may be easier to just execute the configure script at the root of the project. Similarly, there is a deconfigure one which undoes all changes made by configure.

Footnotes

1. Not so simple (for me), though. Notice the amount of commits and numerous failed attempts. ↩

[jeanbarrossilva]

Engaging with the idea of not intercepting the GNU linker of the toolchain, as that appears to not be the actual issue. The problem is, ultimately, SwiftPM, which is not using the version of Swift set in the comment of the on-build package because it is not considering that of the toolchain specified in the execution of xcodebuild/xcrun.

On 0b45a9d, the workflow fails with

Resolve Package Graph
package 'on-build' is using Swift tools version 6.3.0 but the installed version is 6.2.1

Resolved source packages:
  on-build: (null)

xcodebuild: error: Could not resolve package dependencies:
  package 'on-build' is using Swift tools version 6.3.0 but the installed version is 6.2.1

even though dswtc is specified to xcodebuild. This is weird, and makes me think that the problem is not something I am or am not doing, but simply SwiftPM itself, which is using the Xcode-bundled toolchain regardless of such prior specification.

What if we sym link /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain to $(dswtcinfo path)?

[jeanbarrossilva]

As an indication of SwiftPM using the Xcode-bundled Swift toolchain, both

xcrun --show-toolchain-path --toolchain "$(dswtcinfo id)"

and

xcrun --toolchain "$(dswtcinfo id)" --show-toolchain-path

yield

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain

Does SwiftPM execute xcrun?

[jeanbarrossilva]

Bingo.

In SwiftPM…

1. SwiftCommandState initializes and stores a Workspace;
2. UserToolchain is initialized upon an initialization of Workspace;
3. the initializer of UserToolchain calls UserToolchain/determineLibrarian(triple:binDirectories:useXcrun:environment:searchPaths:extraSwiftFlags:fileSystem:);
4. such function returns a result of a call to UserToolchain/findTool(_:envSearchPaths:useXcrun:fileSystem:) when the target triple of the machine is an Apple one;
5. this latter function executes xcrun to find the Swift toolchain SwiftPM will use.

Assuming that this is, in fact, an issue of xcrun, xcrun is not open-source and we, therefore, have no direct power over it to fix this problem. The solution, rather than linker interception, appears to be to sym link the Xcode-bundled toolchain to dswtc.

[jeanbarrossilva]

WHAT

[jeanbarrossilva]

🕺🏽🕺🏽🕺🏽

[jeanbarrossilva]

Update: the fix consists of merely sym-linking the ld of the Swift toolchain required by Deus to that of the Xcode-bundled toolchain.