revisit submodule setup

[incanus]

We should rethink pulling in this library into the native parent by submodule and make them a bit more disconnected. We should be able to make path specification part of the native setup process and have the two libraries anywhere relative to each other.

[incanus]

Ref: https://github.com/mapbox/mapbox-gl-native/blob/master/.gitmodules

[incanus]

Per https://github.com/mapbox/mapbox-gl-cocoa/issues/35#issuecomment-48266730 whether we get rid of submodules is irrelevant. We could do so just to simplify the project, since building the base native library requires manual script running (make setup) anyway so running a git clone manually is no more work than a git submodule update.

[incanus]

So one concern I have here, and part of why I originally set things up this way, is that work on gl-native can progress along without direct gl-cocoa testing. Here's an example. Requiring gl-cocoa to be part of the build/test process of gl-native ensures that breaking changes get caught. Otherwise, you only notice problems once you get back into gl-cocoa development.

[mikemorris]

If you're worried about breaking changes, wouldn't it make most sense to submodule mapbox-gl-native into this project to pin it at a known working gitsha, and update it when releasing new versions of mapbox-gl-cocoa?

[incanus]

I guess I'm seeing the dev workflow differently. In my eyes, and likely in other folks who (will be) working on gl-native by way of gl-cocoa, they are intertwined. When I sit down to work on GL, I rebuild my iOS app and start iterating. Multiple times, I've had to instead spend an hour or two bringing gl-cocoa up to date with gl-native.

A model of integrating changes across all platforms before calling them done in master as @kkaefer has done in cases like https://github.com/mapbox/mapbox-gl-native/pull/445 and https://github.com/mapbox/mapbox-gl-native/pull/527 is great. Otherwise work on the non-majority platform is a land of shifting sands every time you sit down.

[mikemorris]

I'm working on a similar problem, but IMHO the responsibility for adapting to breaking changes should be on downstream modules, not the upstream project. Getting mapbox-gl-native to a semver-stable state would be quite helpful here.

[incanus]

I hadn't thought about the fact that we want the view controller housing (all the app interaction buttons, the setup of what style to use, etc.) to be in both projects.

• gl-native so we have an app to build & integration test with Travis
• gl-cocoa for the same reason the repo even exists — to show example usage and to allow easy spin-up & experimentation

[mikemorris]

We could probably manage some Travis trickery to test deps of gl-native like gl-cocoa (perhaps under an allow failures flag so we know changes are breaking, but without turning the build red), but these projects should depend on gl-native, not the other way around.

[incanus]

Oh, I gotcha. Yeah, lemme see what I can do with that. So this repo (gl-cocoa) becomes:

• A download point for a static lib for Cocoa
• Packaging scripts
• CocoaPods metadata
• Screenshots
• Travis thingies
• But no code

[mikemorris]

Uh, what? Code and everything else in here is fine, it just shouldn't be submoduled into gl-native.

[incanus]

What I'm saying is:

• Code gets moved into gl-native, so that variants of that project are self-contained and can be built, tested, etc.
• Packaging and ways to install a binary for Cocoa alone will exist here.

Basically we do the first part already with the Android code:

https://github.com/mapbox/mapbox-gl-native/tree/master/android

And the Linux:

https://github.com/mapbox/mapbox-gl-native/tree/master/linux

And the Mac:

https://github.com/mapbox/mapbox-gl-native/tree/master/macosx

[mikemorris]

^ Sounds reasonable if ios is considered to be a platform on par with android, osx and linux rather than a project dependent on the gl-native library :+1:

[incanus]

Yeah, iOS is only "bindings" in the sense that integration is trivial because of the way that Objective-C and C++ can work together inline. It's truly a platform on par with the others, and we should undo the separation from the point of view of development process.

[incanus]

@kkaefer has done a good chunk of this just today at https://github.com/mapbox/mapbox-gl-native/tree/integrate-ios

However, the statically-compiled version of the iOS lib, with five architectures (as before) but now also with debug symbols is 227MB.

I'm thinking we could provide both a stripped and this unstripped version, but that if we do, the large unstripped one shouldn't be on GitHub / in Git, but rather on S3.

I'm envisioning several ways to integrate this.

---

Stripped, precompiled, static

Target audience: devs who want to experiment with GL in an iOS app, including style experimentation, taking it around the block, drop-in replacement for MapKit, etc.

• A manual install method for stripped install, as with the dist structure now.
  • Drag Headers into Xcode to copy & alter search paths
  • Drag MapboxGL.bundle into Xcode to copy & alter bundled resources
  • Drag libMapboxGL.a into Xcode to copy & alter linked libraries
• CocoaPods install method for stripped install.
  • Add MapboxGL to Podfile
  • pod install

Stripped, precompiled, dynamic

Target audience: same as above, but also with Swift / playground support.

• Need to research CocoaPods' new Swift / dynamic framework support.

:point_right: When GL is stable, 95% of devs are going to want to go this route anyway.

---

Unstripped, precompiled of any variant

Target audience: ??

• This is in case you want to debug crashes or send crash logs. These would be the only reason you'd favor an unstripped, precompiled library over just building the C++ yourself.
  • Manual same as above, but a much larger libMapboxGL.a
  • CocoaPods using a subspec (I think?) to install a variant like MapboxGL-debug

---

Build & integrate it yourself out of mapbox-gl-native

Target audience: people who want to contribute to the library.

Lastly, we can also just guide people up to mapbox-gl-native if they want to get involved with development in C++ with the whole project. I'm inclined to skip precompiled, unstripped in favor of this.

[incanus]

Ok, we're in good shape with CocoaPods and dynamic frameworks for our currently distributed version:

https://twitter.com/incanus77/status/563488522024140800

[ljbade]

@incanus I would also like something similar with stipped/unstipped binaries on Android.

We need the symbols for debugging crashes from crash logs in the wild, but don't want to distribute huge binaries.

So keepin archive of unstripped looks like a good idea.

[incanus]

Currently playing with dynamic library creation and CocoaPods interaction. @kkaefer I'm happy to pick up your work in the branch and run it to completion, if you like.

[kkaefer]

Great, can we merge this branch before we have a 100% solution for dynamic libraries and symbol distribution? It'd make developing and keeping iOS in sync a lot easier.

[incanus]

Yeah, I will work on that next.

[incanus]

@kkaefer See https://github.com/mapbox/mapbox-gl-native/pull/772#issuecomment-73333879 — seeing this through is a combination of merging the gl-cocoa storage branch, to which gl-native master is pinned, but this doesn't line up with what you've started in integrate-ios.

[incanus]

Fixed by creating a storage-solo branch that just brought over code changes from storage, merged to master, and pinned gl-native to master here.

Now back to restructuring...

[incanus]

This project is now moved up to gl-native as of https://github.com/mapbox/mapbox-gl-native/commit/fdcd1b888bf81a2421992b1a01c16606c858f55f.

Next steps in https://github.com/mapbox/mapbox-gl-cocoa/issues/83.