[swift-build-dev] Test-only dependencies

[Honza Dvorsky]

Good point, I forgot about that.
On Mon, Aug 29, 2016 at 5:36 PM Daniel Dunbar <daniel_dunbar at apple.com>
wrote:

> On Aug 29, 2016, at 2:35 AM, Honza Dvorsky <jan.dvorsky at me.com> wrote:
>
> Not sure if already mentioned, but the issue of duplicated dependencies in
> targets can be easily handled like this:
>
> import PackageDescription
>
> let sharedDependency: Package.Dependency = .Package(url: "...",
> majorVersion: 1)
>
> let package = Package(
>     name: "MyPkg",
>     targets: [
>         .Target(name: "First"),
>         .Target(name: "Second", dependencies: ["First", sharedDependency]),
>         .Target(name: "Third", dependencies: [sharedDependency])
>     ]
> )
>
> That's assuming we'll be able to add external deps to targets.
>
>
> 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.
>
> I would like it if the syntax for all common things was representable as a
> readable declarative initializer.
>
>  - Daniel
>
>
> - Honza
>
> 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
>> 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
>>
>> _______________________________________________
>> swift-build-dev mailing list
>> swift-build-dev at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-build-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160829/2692b1a4/attachment.html>