<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Aug 29, 2016, at 2:35 AM, Honza Dvorsky <<a href="mailto:jan.dvorsky@me.com" class="">jan.dvorsky@me.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Not sure if already mentioned, but the issue of duplicated dependencies in targets can be easily handled like this:<div class=""><br class=""></div><div class=""><div class="">import PackageDescription</div><div class=""><br class=""></div><div class="">let sharedDependency: Package.Dependency = .Package(url: "...", majorVersion: 1)</div><div class=""><br class=""></div><div class="">let package = Package(</div><div class=""> name: "MyPkg",</div><div class=""> targets: [</div><div class=""> .Target(name: "First"),</div><div class=""> .Target(name: "Second", dependencies: ["First", sharedDependency]),</div><div class=""> .Target(name: "Third", dependencies: [sharedDependency])</div><div class=""> ]</div><div class="">)</div></div><div class=""><br class=""></div><div class="">That's assuming we'll be able to add external deps to targets.</div></div></div></blockquote><div><br class=""></div>I'm not sure that is a syntax we want to support per the long term plans to split the manifest into a "leading package specification" which, while Swift, is a restricted subset we know we can parse into a machine editable form.</div><div><br class=""></div><div>I would like it if the syntax for all common things was representable as a readable declarative initializer.</div><div><br class=""></div><div> - Daniel</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">- Honza</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Mon, Aug 29, 2016 at 7:07 AM Daniel Dunbar via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" class="">swift-build-dev@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I completely agree with your original email, and agree the target-access control proposal amounts to a variant of #2.<br class="">
<br class="">
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.<br class="">
<br class="">
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).<br class="">
<br class="">
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.<br class="">
<br class="">
- Daniel<br class="">
<br class="">
> On Aug 28, 2016, at 7:48 PM, Paul Cantrell via swift-build-dev <<a href="mailto:swift-build-dev@swift.org" target="_blank" class="">swift-build-dev@swift.org</a>> wrote:<br class="">
><br class="">
><br class="">
>> On Aug 28, 2016, at 9:23 PM, Ankit Aggarwal <<a href="mailto:ankit_aggarwal@apple.com" target="_blank" class="">ankit_aggarwal@apple.com</a>> wrote:<br class="">
>><br class="">
>> 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.<br class="">
><br class="">
> That’s what I had in mind with “Approach 2” in my original message. Approach 3 is a related but different alternative.<br class="">
><br class="">
> Please see remarks in the original message for my take on the pros and cons.<br class="">
><br class="">
>> 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.<br class="">
><br class="">
> That proposal is getting warm — especially if test packages are _not_ exposed by default, something it seems to me that proposal should specify.<br class="">
><br class="">
> 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:<br class="">
><br class="">
>> 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.<br class="">
><br class="">
> Cheers,<br class="">
><br class="">
> Paul<br class="">
><br class="">
> _______________________________________________<br class="">
> swift-build-dev mailing list<br class="">
> <a href="mailto:swift-build-dev@swift.org" target="_blank" class="">swift-build-dev@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br class="">
<br class="">
_______________________________________________<br class="">
swift-build-dev mailing list<br class="">
<a href="mailto:swift-build-dev@swift.org" target="_blank" class="">swift-build-dev@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-build-dev" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-build-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></body></html>