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 feature at the moment, right (e.g. I can not invoke `swift 
package fetch --enable-new-resolver`).  Will it be in 3.1?

Thank you.
Cheers,
Anton

> On 29 Oct 2016, at 00:18, Daniel Dunbar <daniel_dun...@apple.com> wrote:
> 
> 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 the behavior you expect?
> 
> - Daniel
> 
>> On Oct 28, 2016, at 1:53 PM, Anton Bronnikov via swift-users 
>> <swift-users@swift.org> wrote:
>> 
>> 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 as a submodule, 
>> provides necessary files and exports C functionality into Swift.  This one 
>> also has two versions tagged, 0.0.1 and 0.0.2, each matching corresponding 
>> version within C repository.
>> - Finally, I have an application in Swift, that uses the wrapper package as 
>> a dependency and specifies 0.0.1 as the desired version.
>> 
>> Normally, I would expect that `swift build` would have PM to check out 
>> 0.0.1/0.0.1 versions of the repositories (SwiftWrapper/CLibrary).  However, 
>> in fact what I get is 0.0.1/0.0.2 (in other words, I get the right - older - 
>> version of the wrapper package, but wrong - new - version of the C 
>> submodule).
>> 
>> The use case is to “escort” a C library that is being continuously developed 
>> and used as such (e.g. in Linux community) with its Swift bridge without 
>> having to copy-paste the sources from the original repo into the mirror (so 
>> that the Swift wrapper would only provide the Package.swift, public header 
>> file, and possible a modulemap).
>> 
>> If there are other (better) way to do this, I will be glad to hear.
>> 
>> Thanks for the help.
>> Cheers,
>> Anton
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> 

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to