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

cannot support Cocoapods #16

Closed
chunxige opened this issue Nov 9, 2020 · 5 comments
Closed

cannot support Cocoapods #16

chunxige opened this issue Nov 9, 2020 · 5 comments

Comments

@chunxige
Copy link

chunxige commented Nov 9, 2020

No description provided.

@lorentey
Copy link
Member

lorentey commented Nov 9, 2020

This is a package intended to be used with the Swift Package Manager. Is there a specific reason you cannot add it as a package dependency?

jjatie referenced this issue in ChartsOrg/Charts Feb 26, 2021
* Use Algorithms implementation of binary search

* Use `indexed()` where appropriate

* Update Package.swift to include SwiftAlgorithms

* Use lazy implementation of `prefix(while:)`

For better performance

* Revert "Use lazy implementation of `prefix(while:)`"

This reverts commit 69a303f.
@liuxuan30
Copy link

liuxuan30 commented Feb 26, 2021

Hi @lorentey
our side issue is, we have an open source framework danielgindi/Charts published on pod, and recently we adopted swift-algorithm, similar to this repo, it can only be adopted via SPM.

After we add it as dependency from SPM, when we try to push an update to pod, pod will complain cannot find swift-algorithm, and we cannot workaround it unless anyone push swift-algorithm o swift-atomics to pod.

It then became choosing a side: either drop pod support, or don't use SPM dependency, or we have to do ugly things like maintain a copy of the repo in our code base and update it manually.

@Allan-Nava
Copy link

How can I fix for the .podspec?

Screenshot 2021-04-12 at 13 46 25

@lorentey
Copy link
Member

Adding support for alternate build systems is a maintenance burden we are ill-prepared to handle. I'd much prefer to encourage the use of the Swift Package Manager going forward. Apologies if this seems overly cautious; I understand it is inconvenient not to be able to directly use this repository.

If for some reason you must support build systems that aren't compatible with SPM, then vendoring this library is one way to still depend on it. (The license explains the conditions you need to meet when redistributing the code.)

(Adding support for CMake in #25 already makes me very uncomfortable -- and that's a strictly temporary thing, enabling potential adoption of these packages in the package manager itself while the Windows port is being bootstrapped.)

@lorentey
Copy link
Member

C.f. apple/swift-collections#131

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants