I've been working on a proposal to allow assigning build environment conditions (with the same syntax as for build settings) to target dependencies in the Package Manager manifest to allow setting under which platform or configuration conditions the dependency should be observed.
An implementation is already available if you want to play with it, and some toolchains are available to make that easy:
Just to make sure that I understand this correctly - does this also allow for conditional targets, if you group them under an umbrella target?
Let's take the example from the proposal, with two dependencies - bluetooth and bluetoothlinux. Imagine that these libraries vend a common API, and the author would like to merge the repositories. I'm guessing they would be able to do something like this:
Looks great! I wonder if we should also add ability to conditionalize based on the target triple. That will provide a lot of flexibility and an escape hatch for the platforms (and other information in the triple) SwiftPM doesn’t know about yet. This could also be proposed separately but we might as well consider it while we’re on the topic.
One thing I would like is to have optional system libraries, rather than listing out all of the individual platforms on every single target, and then to add a condition like .when(available: "CoreGraphics"). I really, really dislike the whole iOS, tvOS, watchOS dance. I don't expect that list to get shorter in future, either.
Anyway, the reason why it's relevant to this proposal is that it would possibly mean using a different kind of condition to BuildSettingCondition - more like a TargetAvailabilityCondition.
EDIT (aside): I'd love to test the toolchain, but apparently you can't be trusted, and there doesn't seem to be any way for me to overrule it. The button to not require notarisation in system preferences has gone . As a long-time Mac user - this is, to be completely honest, very sad.
It would be based on what's available in the SDK you're building against.
Yeah that's what I tried first, but the new API requires tools version 5.3, which Xcode refuses to work with, even with the new toolchain selected ("/.../Package.swift: package at '...' is using Swift tools version 5.3.0 but the installed version is 5.1.0")
You might want to run swift build directly from the command line. To have the CLI select this toolchain, define the following environment variable. To check that it works, check the output of xcrub --find swift:
$ export TOOLCHAINS=org.swift.pr.28041.441
$ xcrun --find swift
Then, when you run swift build, it should popup a different interface that WILL allow you to accept the consequences of trusting me ;)
Nice try - the export line does at least ensure the correct CLI tools are selected (switching in Xcode doesn't seem to do anything to the CLI anymore). I have no reason to doubt your trustworthiness, but apparently Apple does, so... who am I to argue?