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

> Not in practice (with respect to package manifests). In fact, it seems > that, given there are separate commands (swift build and swift test), > separate directories (Sources and Tests), and separate products, that > there's a hole to be filled here by separate handling for test suites in >

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

On Thu, Jan 26, 2017 at 1:55 PM, Robert Widmann via swift-evolution < swift-evolution@swift.org> wrote: > Three parts for three points: > > 1) Thanks! > > 2) I'm not sure generalizing this is particularly useful post-products. > The larger point is not to have non-exported/local target

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

afar as I don't have much SwiftPM > experience, but if that is true, what's the point of the proposal? > > > > > On 26 Jan 2017, at 08:12, Ankit Agarwal via swift-evolution < > swift-evolution@swift.org> wrote: > > > > > > The test targets are *not* comp

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

On Thu, Jan 26, 2017 at 6:37 AM, thislooksfun via swift-evolution < swift-evolution@swift.org> wrote: > I still much prefer 'testDependencies/Targets'. You seem to be confusing > this proposal with the (already accepted) Package Manager Product > Definitions >

Re: [swift-evolution] SwiftPM C++ Support

+ swift-build-dev On Tue, Jan 17, 2017 at 12:03 AM, Harlan Haskins via swift-evolution < swift-evolution@swift.org> wrote: > Hi swift-evolution! > > Robert Widmann and I have been working on a Swift wrapper for LLVM ( > https://github.com/harlanhaskins/LLVMSwift) and we’re lamenting the lack >

Re: [swift-evolution] [swift 4] static libs/modular code, fixed-size arrays, ref/pointer to structs, pointers, numeric types.

> Swift, with its extension concept, is very well suited to modular > development like this. We'd like to have a better option than frameworks to > build reusable libraries. It's not an ABI thing, we really don't care about > that, we use libs just to organize code, building them as a part of the

Re: [swift-evolution] [Review] SE-0129: Package Manager Test Naming Conventions

> * What is your evaluation of the proposal? > +1 to proposal. This will be a good change to make conventions more clearer and a step towards supporting test specific libraries. > * Is the problem being addressed significant enough to warrant a > change to Swift? > Yes, the

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

On Wed, Jul 13, 2016 at 9:27 PM, Anders Bertelrud wrote: > Thanks for taking the initiative for this, Ankit. It's a very welcome > improvement. > > Comments inline. > > On 2016-07-12, at 11.15, Ankit Agarwal via swift-build-dev < > swift-build-...@swift.org> wrote: > > To mark

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

I have updated the proposal accommodating recent discussion Link: https://github.com/aciidb0mb3r/swift-evolution/blob/swiftpm-module-access-control/proposals/-swiftpm-target-access-control.md SwiftPM Target Access Control - Proposal: SE-

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

> 1. One major reason for wanting control over which targets are exported > are so packages can control which parts of their API is supported for > external use. This is very important to large projects undergoing active > development while also trying to support a well-defined, semantically >

Re: [swift-evolution] Proposal: SwiftPM Target Access Control

I agree with Tanner, an AccessControl enum clearly defines the access of a target and provides flexibility for future. On Fri, Jul 8, 2016 at 3:17 AM, Tanner Nelson wrote: > Really happy to see this proposal. It will cut build times for packages > that use my library

Re: [swift-evolution] [swift-build-dev] Proposal: SwiftPM Target Access Control

Hi, Thanks for feedback. I agree that specifying external dependencies with targets would be great. I think the only thing issue is to figure out is how to specify them. Some thoughts: Note: Currently target name has to be unique across all the targets in the package (including its

[swift-evolution] Proposal: SwiftPM Target Access Control

Hi swift packagers, I am proposing access control to package targets. Link: https://github.com/aciidb0mb3r/swift-evolution/blob/swiftpm-module-access-control/proposals/-swiftpm-target-access-control.md Feedback appreciated! SwiftPM Target Access Control - Proposal: SE-

Re: [swift-evolution] [swift-build-dev] [Review] SE-0085: Package Manager Command Names

+1 to spm or swiftpm (in that order) As a swiftpm user I would imagine it works like : spm -> builds spm test -> runs tests spm init -> new project On Tue, May 10, 2016 at 1:12 PM, Rob Allen via swift-build-dev < swift-build-...@swift.org> wrote: > > > On 9 May 2016, at 23:05, Daniel Dunbar via

Re: [swift-evolution] [Review] SE-0063: SwiftPM System Module Search Paths

> * What is your evaluation of the proposal? > I am in favour of this proposal. It will solve an important problem faced by swiftpm users. > * Is the problem being addressed significant enough to warrant a > change to the Swift Package Manager? > Yes, system modules often

Re: [swift-evolution] [Draft] SwiftPM: Adding development package as a dependency

On Fri, Apr 1, 2016 at 10:45 PM, Max Howell wrote: > I’m wondering if the dev package should be inside Packages in some manner, > perhaps as a symlink. > > Otherwise when you looks inside Packages you don't see all your > dependencies. > Since as per current design dev

Re: [swift-evolution] [Draft] SwiftPM: Adding development package as a dependency

On Wed, Mar 30, 2016 at 6:05 AM, James Richard wrote: > It's be nice to include a bit about how these interact with generated > Xcodeproj files. In Cocoapods those end up in a separate grouping, which I > find to be beneficial. > It should do the same as it does for other

Re: [swift-evolution] [swift-build-dev] [Draft] SwiftPM: Adding development package as a dependency

On Wed, Mar 30, 2016 at 1:10 AM, Max Howell wrote: > 1) You have to remember to modify it back at some point, and if you are >>> iterating frequently this is tedious and error-prone >>> >> >> One way I can think of to avoid Package.swift is to place DevPackages >> inside

Re: [swift-evolution] [swift-build-dev] [Draft] SwiftPM: Adding development package as a dependency

> This was more or less what I’ve been thinking, but lately I’ve been also > thinking it would be great if: > > You didn’t have to modify Package.swift to get this feature. > > Because: > > 1) You have to remember to modify it back at some point, and if you are > iterating frequently this is

[swift-evolution] [Draft] SwiftPM: Adding development package as a dependency

SwiftPM: Adding development package as a dependency - Proposal: SE- - Author(s): Ankit Aggarwal - Status: *Awaiting review* - Review manager: TBD Introduction I

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

> > It is a convention to name the .pc file after the library link-name, so > we can determine which .pc file to ask pkg-config for by parsing the > .modulemap file in the Swift package. what about the cases where .pc file doesn't matches the link-name from modulemap for eg : gtk+2 or 3 has

Re: [swift-evolution] [swift-build-dev] [Proposal] Lock file for Swift Package Manager

Thank you all for the valuable feedback I have updated the proposal to reflect the changes which are agreed upon by majority. Please go through the updated proposal below and provide more feedback. Lock File for Swift Package ManagerIntroduction A Package.lock file containing list of resolved

[swift-evolution] [Proposal] Lock file for Swift Package Manager

Lock File for Swift Package ManagerIntroduction A Package.lock file containing list of resolved dependencies generated by swiftpm. Motivation Package.lock file can be helpful in situations like : Reproduce exact versions of dependencies on different machine * Multiple developers working on a