CMake: Fixing cross-compiling Swift-Foundation

[etcwilde]

The macros must build for the local machine running the build, not the machine that Swift-Foundation will run on, in order for the build to be able to use the macros.

To do this, the macro build must use ExternalProject, which treats the child project as an entirely independent project. One cannot introspect into the external project since it is configured at build time, rather than at configure time. This is what allows the external project to build for another platform.

The expectation is that the calling project will pull the built products of the ExternalProject from the install location. EPs have an internal implicit install prefix where they can install stuff to without dirtying the building machine or installed products, so we can make use of that. In order for that to work, the products must actually get installed though, so we have to install the FoundationMacros, even when built as an executable. To support that, I've exposed an option to tell the macro build to build the macros as an executable.

On the library side, I've exposed the Foundation macros as an interface library that only exposes the -load-plugin-path option needed for picking up the macro. Linking against this interface library will load the plugin as desired.

This results in a build that

• can use macros, even when cross-compiling.
• does not install the macros into the installed library, only to the build directory.

[etcwilde]

@swift-ci please test

[jmschonfeld]

I haven't seen the <INSTALL_DIR> syntax before, out of curiosity, what does it mean?

[compnerd]

This is a special placeholder that will be filled in with the install path. This is documented in the ExternalProject documentation IIRC.

[etcwilde]

@swift-ci please test

[jmschonfeld]

One minor comment, otherwise this looks good to me. Before merging, lets run a cross-repo CI test to get a full toolchain test going with this since this repo's CI doesn't test the cmake build yet

[etcwilde]

@swift-ci please test

[jmschonfeld]

Approved assuming cross-repo test comes back clean, thanks for updating this!

[jmschonfeld]

-- SwiftSyntax_DIR not provided, checking out local copy of swift-syntax

Looks like we need to make sure SwiftSyntax_DIR gets passed along to the separate macro build

[etcwilde]

Looks like we need to make sure SwiftSyntax_DIR gets passed along to the separate macro build

Except that was built for the machine we're building the toolchain for, not the machine we're building the toolchain on.
(Assuming I'm reading build-script right)

We can, however, set <lowercaseName>_SOURCE_DIR so that we're not cloning it again. https://cmake.org/cmake/help/latest/module/FetchContent.html#command:fetchcontent_makeavailable

[jmschonfeld]

Actually I got my wires crossed - in the toolchain build, swift-foundation should already receive SwiftFoundation_MACROS from the build script so it shouldn't ever hit the ExternalProject path, right?

[etcwilde]

@swift-ci please test

[etcwilde]

@swift-ci please test

[finagolfin]

Is this really necessary? When cross-compiling this repo on the CI, you use a current freshly-built host toolchain from the same source, which already has these macros compiled and installed for the host. I haven't had any problem cross-compiling these new Foundation repos that way.

What I'd like instead is an option to disable cross-compiling these macros too, which is only useful for cross-compiling the toolchain, but not for standalone SDKs. For example, I'm cross-compiling an Android SDK using build-script right now and had to manually patch out cross-compiling these macros on there.

Btw @etcwilde, there appears to be a problem with building for Swift with the current CMake 3.30. You added the CMAKE_SHARED_MODULE_CREATE_Swift_FLAGS when building shared libraries, then set it for Apple-Swift alone later in that commit, which likely worked fine because that variable was uninitialized on other platforms.

However, a little later Brad default-initialized that variable for all languages to the C flags, which appears to have broken linking Swift libraries whenever the C flags are set on non-Apple platforms, by passing in C linker flags like -Wl,--build-id=sha1 to the Swift compiler. Never mind, that's not the reason. Comparing previous CMakeCache.txt files, these C linker flags were always set for CMAKE_SHARED_LINKER_FLAGS from the Android NDK, but CMake was careful to apply them only for C/C++ libraries like lib_FoundationICU.so and not for other language libraries like libFoundationEssentials.so.

However, something changed in the CMake source with 3.30 and it is now indiscriminately applying those C linker flags to all languages' shared libraries in mixed language CMake projects like this, breaking other languages like Swift.