> On Oct 29, 2016, at 7:22 AM, Anton Bronnikov wrote:
>
> Thanks, Daniel.
>
> Yes, on Oct-27 snapshot `Swift version 3.0-dev (LLVM b52fce3ab4, Clang
> 4edf31e82f, Swift bf2de4a41c)` if I build with `swift build
> --enable-new-resolver` then I do get the expected behaviour. Building with
> u
Thanks, Daniel.
Yes, on Oct-27 snapshot `Swift version 3.0-dev (LLVM b52fce3ab4, Clang
4edf31e82f, Swift bf2de4a41c)` if I build with `swift build
--enable-new-resolver` then I do get the expected behaviour. Building with
usual `swift build` gets me an old - wrong - one.
It’s an experimental
This sounds like a bug to me, I suspect that the current code isn't causing the
submodule to update appropriately.
If you have a working example, can you try using the latest OSS snapshot from
swift.org, and running:
swift package reset
swift build --enable-new-resolver
and seeing if you get
Hi,
I have a question whether what I observe is by-design, a bug, or not yet fully
implemented feature in Swift Package Manager.
- Let’s say, I have a C repository with some library, and it has two versions
tagged, namely 0.0.1 and 0.0.2.
- Then I have a Swift repository that includes the above
