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

Look at changing permission adapters to not use weak linking #147

Open
marcpalmer opened this issue Jul 10, 2018 · 0 comments
Open

Look at changing permission adapters to not use weak linking #147

marcpalmer opened this issue Jul 10, 2018 · 0 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@marcpalmer
Copy link
Contributor

Following the landing of workaround #145, we'd like to look at more sustainable solutions. Something like one of:

  1. Microframeworks (more hassle for user, can link without tricks though, more relinking overhead, more git admin/release busywork)

  2. App-side protocols that mimick the APIs required, assigning instances to e.g. Flint.contactStore so permission adapter can use them. We still can't use the real APIs inside FlintCore in this scenario

  3. Swift compiler defines passed to Carthage/Cocoapods at build time to specify which modules are required e.g. OTHER_SWIFT_FLAGS=-DFLINT_CONTACTS -DFLINT_PHOTOS and we wrap all access and imports of such APIs with checks for those. Fiddly for users/config as you can't just check out the project and build it, but lets us use all the APIs.

@marcpalmer marcpalmer added enhancement New feature or request help wanted Extra attention is needed labels Jul 10, 2018
@marcpalmer marcpalmer added this to the 1.0 milestone Jul 10, 2018
@marcpalmer marcpalmer modified the milestones: 1.0, 1.1 May 6, 2019
@marcpalmer marcpalmer removed this from the 1.1 milestone May 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

1 participant