plugins: Build command plugin dependencies for the host, not the target

[euanh]

Motivation:

When cross-compiling, SwiftPM plugins and their dependencies run on the host and so must be compiled for the host OS and architecture, not the cross-compiled target OS and architecture. SwiftPM will
compile a command plugin for the host but if the plugin depends on an executable it will cross-compile the executable for the target so the plugin will not be able to run it:

error: Error Domain=NSPOSIXErrorDomain Code=8 "Exec format error"

This problem does not affect binaryTarget dependencies, which are handled by a different code path which correctly selects the the binary for the host system from the archive.

Modifications:

Command plugin dependencies are already handled specially in PluginCommand.run; this commit makes that special build step use the host toolchain instead of the target toolchain.

#6060 handled the equivalent problem for build tool plugins.

Result:

Executables which are are dependencies of command plugins will be built for the host OS and architecture, so the plugins will be able to run them.

[MaxDesiatov]

Can we come up with a test for it in SwiftToolTests.swift?

[euanh]

Can we come up with a test for it in SwiftToolTests.swift?

I think regression testing for the normal case where we are not cross-compiling is already covered. I have been testing locally with a test case which turns out to be very similar to testLocalAndRemoteToolDependencies(): a command plugin which depends on an executable target. I would expect this test to fail if the plugin dependency build flow was broken.

One difference is that my local test also has a top-level target which we can check is cross-compiled, in addition to the command plugin which should be built for the host. However I don't think we yet have testing infrastructure to set up a cross-compiler. Is there a way to fake enough of a cross-compliation SDK to show that swift package does the right thing in this case?

I'd be happy to add my test but I think it would just duplicate what's already there.

[MaxDesiatov]

@swift-ci smoke test

[euanh]

For reference, here is the test I've been using locally: CommandPluginDependencies.zip

If you run the plugin without a cross-compilation SDK you should see the following output:

% swift package plugin my-command-plugin
Building for debugging...
[1/3] Emitting module MyHelperToolLib
[2/3] Compiling MyHelperToolLib lib.swift
[3/5] Compiling MyHelperTool main.swift
[4/5] Emitting module MyHelperTool
[4/5] Linking MyHelperTool
Build complete! (1.75s)
Hello from MyHelperTool
Plugin succeded!

If you run it with a cross-compilation SDK without the fix in this PR, it will fail because MyHelperTool will be built for the cross-compilation target:

% swift package --experimental-swift-sdk $X86_LINUX_SDK plugin my-command-plugin 
Building for debugging...
[1/5] Compiling MyHelperToolLib lib.swift
[2/5] Emitting module MyHelperToolLib
[4/7] Wrapping AST for MyHelperToolLib for debugging
[6/9] Compiling MyHelperTool main.swift
[7/9] Emitting module MyHelperTool
[9/11] Wrapping AST for MyHelperTool for debugging
[10/11] Linking MyHelperTool
Build complete! (4.13s)
error: Error Domain=NSPOSIXErrorDomain Code=8 "Exec format error"

This is because both MyService and MyHelperTool have been cross-compiled for the target and can't run on the host:

% file .build/x86_64-unknown-linux-gnu/debug/MyService .build/x86_64-unknown-linux-gnu/debug/MyHelperTool
.build/x86_64-unknown-linux-gnu/debug/MyService:    ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
.build/x86_64-unknown-linux-gnu/debug/MyHelperTool: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped

If you apply the fix in this PR, the build will succeed. MyService will still be cross-compiled, but MyHelperTool will be built for the host:

% file .build/x86_64-unknown-linux-gnu/debug/MyService .build/x86_64-apple-macosx/debug/MyHelperTool
.build/x86_64-unknown-linux-gnu/debug/MyService: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, with debug_info, not stripped
.build/x86_64-apple-macosx/debug/MyHelperTool:   Mach-O 64-bit executable x86_64

[MaxDesiatov]

Thanks for fixing this! SGTM as it was tested manually. We certainly should improve SwiftTool testing infrastructure to cover cross-compilation in the future.