Re: [swift-evolution] [swift-build-dev] [Pitch] Swift run Command

Hi, Thanks a lot for working on this. I am in favour of the proposal. We can nitpick on the name (swift run, swift package run, swift execute) but otherwise this looks like a reasonable feature to add. On Mon, May 15, 2017 at 1:17 PM, David Hart via swift-build-dev <

[swift-evolution] [Accepted] SE-0175: Package Manager Revised Dependency Resolution

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md Hello Swift Community, The review of SE-0175 "Package Manager Revised Dependency Resolution” ran from May 2...May 9, 2017. The proposal is accepted for Swift 4.

[swift-evolution] [Review] SE-0175 Package Manager Revised Dependency Resolution

Hello Swift community, The review of "SE-0175 Package Manager Revised Dependency Resolution" begins now and runs through May 9, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

We discussed variadic overloads during the manifest redesign proposal but ultimately rejected it. We could add an overload for a singular source file (instead

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

g> wrote: > >> On Mar 24, 2017, at 1:26 PM, Ankit Aggarwal via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> sources: This property defines the source files to be included in the >> target, relative to the target path. The default value

Re: [swift-evolution] [Draft] Package Manager Custom Targets Layout

> Is the default *not* recursively searching for source files? If not, it > would be great to have ways that achieve that, e.g. `*.swift`. > The default *is* searching recursively. There will be globbing support in future that allows `*.swift` but for now we will (recursively) search for valid

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

Hi Joesph, Thank you for the feedback! > For the C target classes, I'd like to also see linker flags defined for > those packages, as currently that has to be included in additional flags > and maintained entirely outside the package structure with scripting, > Makefiles, or the like. That may

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Custom Targets Layout

Hi Karl, Thank you for the feedback, comments inline. > 1) I’m not sure about listing all of the test targets together with the > product targets. I feel it may be better to have them as separate Arrays. > They both are similar entity so they stay together. Another example is products, which

[swift-evolution] [Draft] Package Manager Custom Targets Layout

Hi, We would love to get some feedback on a draft proposal for defining custom target layouts in the Package Manager. This proposal allows overriding the target layout rules set by the Package Manager and simplifies some complex "magic" behaviours. You can find the proposal at the link

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

Hi, > – Dave Sweeris' point about this reading wrong in English as > .upToNextMajor("x.y.z") (vs. of "x.y.z".upToNextMajor) makes sense to us too. > As a result, we're going to clarify this by changing it to > .upToNextMajor(after:"x.y.z") and .upToNextMinor(after:"x.y.z"). The "after" in

Re: [swift-evolution] [swift-build-dev] [Review] SE-0158 Package Manager Manifest API Redesign

> +1, although I don’t know why we're supporting this: > > // 1.5.8 ..< 2.0.0.package(url: "/SwiftyJSON", from: "1.5.8"), > > when, at least as far as I can tell, this: > > // 1.5.8 ..< 2.0.0.package(url: "/SwiftyJSON", .uptoNextMajor("1.5.8")), > > does the same thing, and the spelling is, at

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

Hi, Thank you all for the feedback so far. I have updated the proposal: https://github.com/aciidb0mb3r/swift-evolution/blob/manifest-api-redesign/proposals/-package-manager-manifest-api-redesign.md The major changes are: * Drop SystemPackageProvider struct upgrade. * Drop the identity rule.

Re: [swift-evolution] [swift-build-dev] [Draft] Package Manager Manifest API Redesign

Hi David, Thanks for the feedback! Comments inline: On Sun, Feb 26, 2017 at 5:08 AM, David Hart via swift-build-dev < swift-build-...@swift.org> wrote: > Was looking forward to this :) here are my comments: > > On 25 Feb 2017, at 01:35, Rick Ballard via swift-evolution < >

Re: [swift-evolution] [Draft] Test-Only Package Dependencies and Targets

> On 25-Jan-2017, at 4:02 AM, Robert Widmann via swift-evolution > wrote: > > Hello Swift Community, > > Harlan Haskins and I have been working on libraries > to make interacting with LLVM and Clang’s > APIs more elegant with native

[swift-evolution] Proposal: Package Manager Version Pinning

Hi, We're proposing version pinning feature in Swift Package Manager. The proposal is available here and also in this email: Feedback welcomed! Thanks, Ankit Package Manager