[swift-build-dev] Test-only dependencies
jan.dvorsky at me.com
Mon Aug 29 04:35:13 CDT 2016
Not sure if already mentioned, but the issue of duplicated dependencies in
targets can be easily handled like this:
let sharedDependency: Package.Dependency = .Package(url: "...",
let package = Package(
.Target(name: "Second", dependencies: ["First", sharedDependency]),
.Target(name: "Third", dependencies: [sharedDependency])
That's assuming we'll be able to add external deps to targets.
On Mon, Aug 29, 2016 at 7:07 AM Daniel Dunbar via swift-build-dev <
swift-build-dev at swift.org> wrote:
> I completely agree with your original email, and agree the target-access
> control proposal amounts to a variant of #2.
> We definitely need a per-target dependency solution, and if we got one
> that included some kind of solution for managing the duplicate declaration,
> that would solve the con you list with #2. That might suggest that one
> approach here is to add it the list of reasons we should do a per-target
> dependency proposal.
> On the other hand, that has proven more complicated than approach #1, and
> is likely to take longer to get right. I wonder if there are reasons we
> might end up wanting #1 even if we had a working #2 (one reason might be if
> we couldn't solve the duplicate declaration problem).
> My leaning here is towards trying to figure out a good approach for #2
> first, and see where that leaves us, but I could probably be persuaded that
> the problem is pressing enough we should consider a more targeted fix
> - Daniel
> > On Aug 28, 2016, at 7:48 PM, Paul Cantrell via swift-build-dev <
> swift-build-dev at swift.org> wrote:
> >> On Aug 28, 2016, at 9:23 PM, Ankit Aggarwal <ankit_aggarwal at apple.com>
> >> I agree that building test specific dependencies is not useful for
> packages which just uses the some package, however I think that should be
> controlled by some other general mechanism like specifying exact external
> package/target the target in question depends on.
> > That’s what I had in mind with “Approach 2” in my original message.
> Approach 3 is a related but different alternative.
> > Please see remarks in the original message for my take on the pros and
> >> That way all the unused targets in an external package will not build.
> See thread “Proposal: SwiftPM Target Access Control“ for some more
> discussion on this idea.
> > That proposal is getting warm — especially if test packages are _not_
> exposed by default, something it seems to me that proposal should specify.
> > The new “External” in that proposal has the right semantics, but seems
> to me to add yet more complexity to a package DSL whose readability is
> already a bit strained. In particular, this seems likely to cause confusion:
> >> An external package dependency declaration implicitly becomes
> dependency of each target in the package. We propose this behaviour should
> be retained but if a target dependency contains an External declaration
> then all other targets which wants to use that external dependency should
> explicitly state their dependency on that external package using External.
> > Cheers,
> > Paul
> > _______________________________________________
> > swift-build-dev mailing list
> > swift-build-dev at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-build-dev
> swift-build-dev mailing list
> swift-build-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-build-dev