Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XCFramework for SwiftCurrent_Testing #110

Closed
Tyler-Keith-Thompson opened this issue Aug 19, 2021 · 10 comments
Closed

XCFramework for SwiftCurrent_Testing #110

Tyler-Keith-Thompson opened this issue Aug 19, 2021 · 10 comments
Labels
enhancement New feature or request

Comments

@Tyler-Keith-Thompson
Copy link
Collaborator

We've got other XCFrameworks for all of our packages except for SwiftCurrent_Testing. It would be good to add that as well, if we can.

@Tyler-Keith-Thompson Tyler-Keith-Thompson added the enhancement New feature or request label Aug 19, 2021
@Richard-Gist Richard-Gist added this to Backlog in SwiftCurrent Kanban Aug 20, 2021
@morganzellers morganzellers moved this from Backlog to To Do in SwiftCurrent Kanban Oct 25, 2021
@morganzellers morganzellers moved this from To Do to In progress (NaN) in SwiftCurrent Kanban Oct 25, 2021
@morganzellers morganzellers moved this from In progress (NaN) to To Do in SwiftCurrent Kanban Jan 6, 2022
@morganzellers morganzellers moved this from To Do to In progress (NaN) in SwiftCurrent Kanban Jan 25, 2022
@nickkaczmarek
Copy link
Contributor

For the layman, why would we do this? What does using an XCFramework for this buy us?

@Tyler-Keith-Thompson
Copy link
Collaborator Author

It's just another distribution mechanism. I personally feel people should use package managers for a whole host of reasons. That said, there are reasons why people avoid them. For those who want to link to a framework themselves we provide a static framework to link against.

@morganzellers morganzellers moved this from In progress (NaN) to To Do in SwiftCurrent Kanban Mar 3, 2022
@morganzellers
Copy link
Contributor

We will likely be closing this issue, as this is currently not supported with the build tools we use in the pipeline. Additional context for this can be found on the associated PR #149, here, and here.

@nickkaczmarek
Copy link
Contributor

@morganzellers we'll likely want to take a gander at docs to make this explainable to consumers, but writing this to remind myself as well.

@morganzellers
Copy link
Contributor

@nickkaczmarek I'll take a look today and see if there's an appropriate place

@nickkaczmarek
Copy link
Contributor

@morganzellers we may also want to see if there is a way we can zip it up as not a framework in our release.

@morganzellers
Copy link
Contributor

@nickkaczmarek that's a good point... I'm gonna chase that down for a bit

@morganzellers
Copy link
Contributor

So after looking into this, I thought we may be able to archive our test target or wrap it in a project file but it looks like there's not really support for that. Would providing individual test files zipped be of use? I'm not sure.

@nickkaczmarek
Copy link
Contributor

@morganzellers I think it would be worth doing a regular zip on this because we're sort of supporting an edge case where someone might want to use the project, but isn't interested in using a package manager.

@morganzellers
Copy link
Contributor

We will not be offering an XCFramework for the testing package due to the feature differences between xcodebuild and swift build.

See PR #149 for more context. While we will not offer a static framework file for the testing package, we do so for the three main packages, SwiftCurrent, SwiftCurrent_SwiftUI, and SwiftCurrent_UIKit. Users should still be able to try out the library, and should they wish to see the tests themselves, we upload compressed source code with each release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Development

Successfully merging a pull request may close this issue.

3 participants