build iOS runnable app in the style of the OS X one

[incanus]

Ideally launchable from the command-line, but that might be pushing our luck with the simulator. This builds on #21 switch to Gyp.

[incanus]

Bunch of approaches to this, but http://psellos.com/ios/iossim-command-line.html looks to be one of the freshest / most compelling / most self-contained.

[incanus]

Also https://github.com/phonegap/ios-sim comes recommended to me by @landonf, who wrote the original implementation. NPM-installable, too.

[incanus]

Oh yeah, this is gonna work great. Done.

sudo npm install ios-sim -g

[springmeyer]

This would be very cool. Didn't even think this was possible.

[incanus]

Almost building. Looking like this so far:

https://gist.github.com/incanus/1ac9408ce885b644d4b4#file-makefile-L31-L34

Error:

=== BUILD TARGET iosapp OF PROJECT llmr-app WITH THE DEFAULT CONFIGURATION (Release) ===

Check dependencies
target specifies product type 'com.apple.product-type.tool', but there's no such product type for the 'iphoneos' platform

** BUILD FAILED **

The following build commands failed:
    Check dependencies
(1 failure)
make: *** [iapp] Error 65

[incanus]

Beyond this; blocking on libpng Gyp failure now.

[incanus]

Latest: https://gist.github.com/incanus/8762364eb383ae384cb6

[incanus]

Latest fail w/ libpng is related to dylibs:

ld: warning: ignoring file /usr/local/Cellar/libpng/1.5.17/lib/libpng15.dylib, file was built for x86_64 which is not the architecture being linked (armv7): /usr/local/Cellar/libpng/1.5.17/lib/libpng15.dylib

[incanus]

As noted by @springmeyer, we need to somehow build libpng for ARM etc. Best approach is probably documenting this and leaving it up to the user to who needs to build/test on iOS. He's prepping some material to help me set this up.

[springmeyer]

I've documented in the readme in https://github.com/mapbox/llmr-native/commit/8b4b91f6cc272c001c2a2cd956a28d2b8b619b26. Not as clean as I'd like it, but should work. @incanus - Can you check what you have for iOS in when you have a chance so I can test if my universal png libs work okay?

[kkaefer]

@incanus I'm pretty sure that libpng already exists somewhere on iOS, likely buried in a Framework. Alternatively, we can move this to platform.hpp and use an iOS-native library to decode the PNGs.

[incanus]

Good call, I will look into that. It kind of rings a bell, but it would have to indeed be buried because I couldn't find it in the normal places.

[incanus]

No such luck.

How invasive is it to go the native decoding route? That would be really easy in native code. Do you foresee another external lib coming up soon that we'd have to deal with again anyway? (i.e. should we just figure out a pattern for custom-arch external libs?)

[incanus]

@springmeyer working through your Mapnik-based steps now. One note is you now need three arches for device: armv7, armv7s, and arm64, as well as both i386 and x86_64 for simulator (64-bit simulator is now available).

I'm getting errors trying to write to /out but I'll patch that up.

[kkaefer]

@incanus likely candidates for inclusion in the app are HarfBuzz, but not much beyond that. For HarfBuzz, we could substitute Core Text/TextKit, but it'll likely produce slightly different results.

[incanus]

Ok. Let me see how painful building my own libpng is. Again, this is just for us for now and in future, for people hacking on llmr, not end devs using, say, the Cocoa API.

[incanus]

Putting this into a do.sh script instead of typing/pasting direct solved the /out / $BASH_SOURCE problem, so I think I'm about set:

Architectures in the fat file: /Users/incanus/Documents/Projects/Mapbox/vector/llmr.native/mapnik-packaging/osx/out/build-cpp11-libcpp-universal/libpng16.a are: x86_64 armv7s armv7 i386 arm64 

[kkaefer]

if we link to the core framework in the ios app, our lib will also get smaller

[incanus]

Ok I got a build working ok. For practicality, does it make sense to include the build scripts used from mapnik-packaging along with the ios directory in this project?

Here's my calling script that leads to a fat libpng and a successful iOS app build:

https://gist.github.com/incanus/8913d9783e3bc0bab17d

[incanus]

Ok, test app is in master. See ios/README.md. I'll start cleaning up the actual functionality of it (mostly pinch gestures).

The ios-sim thing is a little janky, plus per the README you should test on device anyway. Might work on that later, but it's low priority.

Took care of libpng with ios/setup_libpng.sh. Related: https://github.com/mapnik/mapnik-packaging/pull/119

[springmeyer]

Nice work @incanus - sticking with external/fat libpng for now seems great for now - gets us running fast and helps create a framework for testing other external libs. But I agree with @kkaefer that ideally/long term we try to stay small/core and minimize external libs - I think it just may take some time to figure out the details while right now our focus should be on functionality and ensuring we are cross platform.

[kkaefer]

I'm still getting "building for iOS Simulator, but linking against dylib built for MacOSX file '/opt/X11/lib/libpng15.dylib' for architecture i386"

[kkaefer]

Ah sorry, I didn't run the ios setup script.