[swift-build-dev] Test-only dependencies

[Daniel Dunbar]

> On Sep 6, 2016, at 1:36 PM, Paul Cantrell <cantrell at pobox.com> wrote:
> 
>> 
>> On Aug 29, 2016, at 11:10 AM, Daniel Dunbar <daniel_dunbar at apple.com <mailto:daniel_dunbar at apple.com>> wrote:
>> 
>>> 
>>> On Aug 29, 2016, at 9:00 AM, Paul Cantrell <cantrell at pobox.com <mailto:cantrell at pobox.com>> wrote:
>>> 
>>>> On Aug 29, 2016, at 12:07 AM, Daniel Dunbar <daniel_dunbar at apple.com <mailto:daniel_dunbar at apple.com>> 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.
>>>> 
>>>> …
>>>> 
>>>> My leaning here is towards trying to figure out a good approach for #2 first, and see where that leaves us
>>> 
>>> I’m not up on all the discussion, but that certainly seems to me like the right direction.
> 
> One way to remove the redundant declarations from #2:
> 
> (1) Allow virtual targets that have no corresponding source directory, but declare external dependencies.
> 
> (2) Allow other targets to depend on virtual targets.

This works, but would it be obvious to newcomers? It feels more like a hack rather than something we would explicitly want to be the definitive model for solving the sharing problem.

I do think that allowing such kinds of targets is something that may make sense, I'm just not sure it is the right answer to the redundant declaration.

> So, for this directory structure:
> 
>     Source/
>         ...
>     Tests/
>         FooTests/
>         BarTests/
> 
> …a manifest could declare:
> 
>     targets: [
>       Target(
>         name: "Tests",   // Note that /Tests/Tests does not exist!
>         dependencies: [
>           .Package(url: "https://github.com/Quick/Quick <https://github.com/Quick/Quick>", majorVersion: 0)
>         ]),
>       Target(
>         name: "FooTests",
>         dependencies: ["Tests"])
>       Target(
>         name: "BarTests",
>         dependencies: ["Tests"]),
>     ],
> 
> To that, you could also add:
> 
> (3) All test targets implicitly depend on a virtual target named “Tests.”
> 
> …which would allow this simplification:
> 
>     targets: [
>       Target(
>         name: "Tests”,
>         dependencies: [
>           .Package(url: "https://github.com/Quick/Quick <https://github.com/Quick/Quick>", majorVersion: 0)
>         ])
>     ],
> 
> Note that there’s no longer any need to override convention-based defaults for FooTests and BarTests.
> 
> What do you think?
> 
>>> 
>>>> On Aug 29, 2016, at 10:36 AM, Daniel Dunbar <daniel_dunbar at apple.com <mailto:daniel_dunbar at apple.com>> wrote:
>>>> 
>>>>> On Aug 29, 2016, at 2:35 AM, Honza Dvorsky <jan.dvorsky at me.com <mailto: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)
>>>>> …
>>>>>         .Target(name: "Second", dependencies: ["First", sharedDependency]),
>>>> 
>>>> 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.
>>> 
>>> It’s a tangent, but … doesn’t that defeat the advantage of having the syntax be Swift, namely being able to execute code within the package declaration to eliminate redundancy and conditionally declare things?
>> 
>> No, the intent was to support both cases, but to prioritize the leading package specification being able to describe most scenarios. See:
>>   https://github.com/apple/swift-package-manager/blob/master/Documentation/Internals/SwiftBasedManifestFormat.md <https://github.com/apple/swift-package-manager/blob/master/Documentation/Internals/SwiftBasedManifestFormat.md>
> Thanks for the link. The “Editor Support” section did clarify things quite a bit.
> 
>> If you have concrete examples of things you think are finicky or spelled badly, that is worth raising separately and feeding into a discussion of cleaning up the manifest API.
> 
> The obvious one is knowing which things are enums and which are structs. It’s hard to know when to include the leading dots.

Yes, that is an example of something we know is broken (especially post Swift3 rename) but haven't had time to clean up yet.

 - Daniel

> 
> I’ll give this some separate thought in another thread, as you suggest.
> 
> Cheers,
> 
> Paul

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160906/2a465954/attachment.html>