Support building static libraries on Windows

[compnerd]

Description

Currently, we do not properly build static libraries on Windows due to the way that the library is built. A static library is effectively an archive of the object files (on all platforms), however the mechanism for building the archive is different. Darwin requires a BSD style index, other Unicies prefer a GNU style index (but do not require it). Windows does not require an index but does not have the Unix archiver but rather a dedicated librarian. The librarian is invoked through the linker with a mode specifier (link /LIB).

https://github.com/apple/swift-package-manager/blob/main/Sources/LLBuildManifest/BuildManifest.swift#L91-L99 constructs the ArchiveTool.

This likely is mapped to https://github.com/apple/swift-llbuild/blob/main/lib/BuildSystem/BuildSystem.cpp#L3343-L3345.

The construction of the command then uses https://github.com/apple/swift-llbuild/blob/main/lib/BuildSystem/BuildSystem.cpp#L3303-L3313 which assumes that ar is the tool to build the archive which causes a failure on Windows as there is no archiver.

Expected behavior

No response

Actual behavior

No response

Steps to reproduce

No response

Swift Package Manager version/commit hash

No response

Swift & OS version (output of swift --version && uname -a)

No response

[compnerd]

CC: @artemcm @tomerd @abertelrud

[dmbryson]

As asked offline whether this logic belongs in swiftpm or llbuild, the general philosophy of llbuild is that the specific tool definitions really belong in the clients, like swiftpm, rather than in llbuild. We do have a collection of tools defined, allowing for some basic functionality, but they are largely for testing the library and not intended to be a fully working build system in its own right.

[abertelrud]

Thanks for those comments @dmbryson — I was never sure what the intent was behind having those in llbuild. It does seem to go against the philosophy of llbuild being a low-level engine, with the clients providing the business logic. Sounds like SwiftPM should use ShellCommand for everything and define its own command lines for more control.

[compnerd]

I believe that this was addressed as part of e3a61c0 (#5720).