You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This implements a "lite" version of architecture specialization, piggy-backing on superimposed parameters. The lite part is that we do not actually build an accurate set of architectures per client but instead will build the superset of all architectures required by any client, plus the default set of architectures inherent to the target. This means we might be overbuilding in certain cases, but we should no longer have issues with arches that are required by client targets missing from specialized targets.
Copy file name to clipboardExpand all lines: Sources/SWBCore/DependencyResolution.swift
+32-7Lines changed: 32 additions & 7 deletions
Original file line number
Diff line number
Diff line change
@@ -33,16 +33,25 @@ public protocol TargetDependencyResolverDelegate: AnyObject, TargetDiagnosticPro
33
33
34
34
/// A structure of properties which should be superimposed, that is, imposed on all compatible versions of a target in the build graph. Applying them will coalesce targets in the dependency graph which are otherwise identical except for the presence of these properties.
// If mergeableLibrary is enabled, we only apply it if the dependency is in the target's Link Binary build phase.
57
68
// Note that this doesn't check (for example) linkages defined in OTHER_LDFLAGS, because those are already specifying concrete linkages, and this is used by the automatic merged binary workflow which isn't going to edit those linkages. Projects which want to specify linkages via OTHER_LDFLAGS for merged binaries will need to use manual configuration.
// Otherwise, we need to create a new specialization; do so by imposing the specialization on the build parameters.
958
983
// NOTE: If the target doesn't support specialization, then unless the target comes from a package, then it's important to **not** impart those settings unless they are coming from overrides. Doing so has the side-effect of causing dependencies of downstream targets to be specialized incorrectly (e.g. a specialized target shouldn't cause its own dependencies to be specialized).
if resolver.makeAggregateTargetsTransparentForSpecialization {
768
768
// Aggregate targets should be transparent for specialization, so unless we already have imposed parameters, we will compute them based on the parent of the aggregate unless that is an aggregate itself.
769
769
if imposedParameters ==nil && configuredDependency.target.target.type ==.aggregate && configuredTarget.target.type !=.aggregate {
// FIXME: We eventually will also need to reconcile conflicting requirements, one example: <rdar://problem/31587072> In Swift Build, creating ConfiguredTargets from Targets should take into account minimum deployment target
0 commit comments