[swift-build-dev] Test-only dependencies

[Daniel Dunbar]

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 sooner.

 - 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> wrote:
>> 
>> 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 cons.
> 
>> 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