[swift-build-dev] Test-only dependencies

[Paul Cantrell]

> On Aug 29, 2016, at 11:10 AM, Daniel Dunbar <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.

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", 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", 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.

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/93770e55/attachment.html>