Allow static linking of the SwiftPMDataModel target

[MaxDesiatov]

Motivation:

The SwiftPMDataModel target can't be linked statically at the moment, because it uses type: .dynamic explicitly in the Package.swift manifest file. Dynamic linking makes distribution of CLI tools relying on SwiftPM much harder, since you have to redistribute this dynamic libraries too, with little to no benefit.

Modifications:

New SwiftPMDataModel-auto target is added, which uses the same approach as the SwiftPM-auto target of not specifying the linking type explicitly.

Result:

Tools that utilize the SwiftPM package can use the SwiftPMDataModel-auto target for static linking instead of SwiftPMDataModel.

[abertelrud]

This looks good to me, although I wonder if it would make sense to factor out the list of dependencies into a separate array to make sure that they stay in sync. I suppose the same is true for the existing libSwiftPM. I guess another option would be to dynamically add the "auto" versions of the products using code below the main Package() stanza, deriving the "-auto" form from each of a set of products (or perhaps the other way around, deriving a dynamic-library product from each library named with "-auto"). Not sure if you want to get that creative with this particular PR, but factoring the array seems like it would be good because otherwise they can easily get out of sync.

It's unfortunate that we need both products at all, but until we allow clients to control how dependencies are built, we probably do need to keep both.

[MaxDesiatov]

@abertelrud thanks, that's a great suggestion, which is now implemented.

[MaxDesiatov]

@swift-ci please smoke test

[abertelrud]

Thanks, @MaxDesiatov, this looks like a more robust approach to me. @neonichu or @tomerd any concerns here? I think the greatest danger would have been separate hardcoded lists of targets.

[neonichu]

While we are at making things more robust, should we also express "SwiftPM" as "SwiftPMDataModel" plus the three build related targets?

[abertelrud]

While we are at making things more robust, should we also express "SwiftPM" as "SwiftPMDataModel" plus the three build related targets?

That does assume that SwiftPM will always be a superset of SwiftPMDataModel, which I suppose is a safe bet. And you're only talking about target lists, right, and not actually having one product depend on another?

[neonichu]

That does assume that SwiftPM will always be a superset of SwiftPMDataModel, which I suppose is a safe bet.

That was the intent of the split, right? I guess it could still change in the future, but I think until then this would make sense and could avoid issues if someone is only testing one of the products.

And you're only talking about target lists, right, and not actually having one product depend on another?

Yep, only the target list. We do not support depending on products from the same package today, so that would require further changes.

[MaxDesiatov]

While we are at making things more robust, should we also express "SwiftPM" as "SwiftPMDataModel" plus the three build related targets?

Sorry, I'm not sure I understand. How would that look like?

[tomerd]

While we are at making things more robust, should we also express "SwiftPM" as "SwiftPMDataModel" plus the three build related targets?

I think @neonichu is suggesting that instead of repeating the definition of the shared parts between SwiftPM and SwiftPMDataModel we would do something like:

let swiftPM = (name: "SwiftPM" , targets: [...])
let swiftPMDataModel = (name: "SwiftPMDataModel" , targets: swiftPM.targets + [...])
let autoProducts = [swiftPM, swiftPMDataModel]

[tomerd]

@neonichu or @tomerd any concerns here? I think the greatest danger would have been separate hardcoded lists of targets.

yea this approach seems cleaner and safer

I do have one question tho: what is SwiftPMDataModel used for in the first place / why do we have this product? cc @yim-lee

[abertelrud]

@neonichu or @tomerd any concerns here? I think the greatest danger would have been separate hardcoded lists of targets.

yea this approach seems cleaner and safer

I do have one question tho: what is SwiftPMDataModel used for in the first place / why do we have this product? cc @yim-lee

SwiftPMDataModel is the subset of SwiftPM that includes just its data model, allowing some clients (such as IDEs) that use SwiftPM's data model but not its build system to not have to depend on SwiftDriver, SwiftLLBuild, etc. We should probably have better names here, though that could break some clients.

[MaxDesiatov]

@swift-ci please smoke test

[MaxDesiatov]

Thanks for the clarification. I've updated the PR and added comments to these new product declarations based on your feedback, if you don't mind.

[MaxDesiatov]

As far as I'm aware, this PR can't break things for macOS builds, as those rely on CMake, but on other platforms allowing static linking of this product would be a great improvement for for tools that rely on SwiftPM. Given that this change is not too disruptive, could it be accepted in the 5.5 release branch? Is it worth creating a PR to chery-pick it to that branch?