[swift-build-dev] Test-only dependencies

[Paul Cantrell]

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

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

The package syntax is already a bit hard on the eyes, and quite finicky. (When do you use “.”? What is the correct order for all those named args?) If it’s going to be a bespoke syntax anyway, I’d vote for abandoning Swift syntax altogether and focusing on readability.

(Apologies if I’m reopening a well-trodden discussion.)

Cheers,

Paul


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20160829/6ef93302/attachment.html>