Introduce static library product

[s1ddok]

This is particularly useful when creating standalone executables. Generated Xcode project doesn't support this AFAICS, but swift build handles it just right.

[CodaFi]

Do you have a hard requirement for this to be a static library? If not, we can just switch the existing product to automatic instead of adding another.

[s1ddok]

I just saw this pattern in SwiftPM docs:

let package = Package(
    name: "Paper",
    products: [
        .executable(name: "tool", targets: ["tool"]),
        .library(name: "Paper", targets: ["Paper"]),
        .library(name: "PaperStatic", type: .static, targets: ["Paper"]),
        .library(name: "PaperDynamic", type: .dynamic, targets: ["Paper"]),
    ],

...

I just want to explicitly cite in my Package.swift that ClangSwift is statically linked hence llvm doesn't need to be installed on the host machine

[CodaFi]

The package manager is going to build a copy of this library if it’s cited as a dependency at least once, no matter if it’s static or dynamic. The way around this would be distributing a static archive, but that’s inherently dangerous and unsupported.

[s1ddok]

Does introducing additional explicit products for Static/Dynamic linkage actually create any problems?

I guess SwiftPM will only build the products that are used as a dependency, so adding those additional ones looks like giving a bit more control to library users, no?

[CodaFi]

It’s not that it creates problems, just that it’s simpler to let the package manager sort these things out if we can help it. FWIW, the current package manager tries to statically link automatic targets as much as possible.