Swift Package Manager and Git submodules


(Anton Bronnikov) #1

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


(Daniel Dunbar) #2

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


(Anton Bronnikov) #3

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_dunbar@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


(Daniel Dunbar) #4

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`).

You should be able to use it almost everywhere, but yes it isn't on by default because there are a couple pieces not done.

Will it be in 3.1?

We are working to switch over to it ASAP, but I don't know exactly when that will happen. I hope w/in a month or two.

- Daniel

···

On Oct 29, 2016, at 7:22 AM, Anton Bronnikov <anton.bronnikov@me.com> wrote:

Thank you.
Cheers,
Anton

On 29 Oct 2016, at 00:18, Daniel Dunbar <daniel_dunbar@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