Skip to content
This repository has been archived by the owner on May 9, 2018. It is now read-only.

get working with CocoaPods 0.36b & frameworks #580

Closed
incanus opened this issue Feb 5, 2015 · 8 comments
Closed

get working with CocoaPods 0.36b & frameworks #580

incanus opened this issue Feb 5, 2015 · 8 comments

Comments

@incanus
Copy link
Contributor

incanus commented Feb 5, 2015

Per http://blog.cocoapods.org/Pod-Authors-Guide-to-CocoaPods-Frameworks/ we need to get with the upcoming CocoaPods which works with dynamic frameworks and thus Swift.

MBXMapKit checks out ok as-is, but is:

  • A much smaller project.
  • An easy naming scheme (MBXMapKit vs. Mapbox-iOS-SDK, which has illegal characters for Clang modules).
  • Far fewer headers.
  • No dependencies itself.

Looks like we need stuff like:

  • Podspec module_name = 'Mapbox_iOS_SDK'
  • Podspec public_header_files that lines up with Mapbox.h
  • ??
@friedbunny
Copy link
Contributor

CocoaPods 0.36.0 was released today and nothing appears to be broken, at least.

When forcing the podfile into use_frameworks! mode everything compiles and runs, but we get Apple Mach-O Linker Warning: Embedded dylibs/frameworks only run on iOS 8 or later for each pod.

Using #import "Mapbox.h" still works, too.

@friedbunny
Copy link
Contributor

I think the existing podspec is good to go, with the optional addition of:

m.public_header_files = 'Mapbox.h'

Why not rename?

  • Changing the pod name would break consumers' existing podfiles (is my understanding)
  • Mapbox-iOS-SDK automatically gets renamed to Mapbox_iOS_SDK where it matters, anyway

Have not yet tested this out in a Swift project.

@friedbunny
Copy link
Contributor

podfile for testing:

pod 'Mapbox-iOS-SDK', :git => 'https://github.com/friedbunny/mapbox-ios-sdk.git', :branch => '0.36-cocoapods'
#pod 'mapbox-ios-sdk'

use_frameworks!

@friedbunny
Copy link
Contributor

And Xcode is melting my brain.

In order to get the pod working as a framework we'll have to change most [NSBundle mainBundle] to [NSBundle bundleForClass:[self class]].

Upon actually using the right path for m.public_header_files = 'MapView/Map/Mapbox.h', it seems like it'd be easier to use *.h rather than Mapbox.h.

@jbardini
Copy link

jbardini commented Apr 3, 2015

It looks like only [RMMapView pathForBundleResourceNamed:ofType:] needs to use [NSBundle bundleForClass], as the other places that use [NSBundle mainBundle] seem to intend to access the application bundle.

Everything seems to be working fine with either static lib and framework: 1184dad

@incanus
Copy link
Contributor Author

incanus commented Apr 13, 2015

How do things look with the above two commits? I've been hacking a bit to get the SDK working in CocoaPods 0.36.3 with use_frameworks! and a Swift app and this appears to work well.

@jbardini
Copy link

I've been using it for a while and had no problems so far.

@incanus
Copy link
Contributor Author

incanus commented May 4, 2015

The 1.6.1 release recently rolled these in and CocoaPods works well.

@incanus incanus closed this as completed May 4, 2015
earltedly referenced this issue in activeintime/mapbox-ios-sdk Jul 13, 2015
…to release

# By Justin R. Miller (12) and others
# Via Jason Wray (3) and others
* 'release' of https://github.com/mapbox/mapbox-ios-sdk:
  Strengthen GL language, add Swift Offline example
  update private header matches
  bump podspec version
  updated changelog for 1.6.1
  explicit public headers in podspec
  explicit module name
  podpsec formatting improvements
  refs #580: pare down Proj4 headers to barest needed for CocoaPods
  refs #580: properly find CocoaPods-based resource bundle
  Smooth edges of user location annotation icon's shadow
  ensure access token is set for v4 API access
  update link
  #578: Unrequire access token for large tiles
  fixes #601: catch bad token during development
  fixes #581: properly check for valid offline source
  Add NSLocationAlwaysUsageDescription check to assert
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants