Skip to content
This repository has been archived by the owner on Aug 8, 2023. It is now read-only.

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

Closed
incanus opened this issue Feb 1, 2014 · 23 comments
Closed

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

incanus opened this issue Feb 1, 2014 · 23 comments
Assignees

Comments

@incanus
Copy link
Contributor

incanus commented Feb 1, 2014

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

@ghost ghost assigned incanus Feb 1, 2014
@incanus incanus mentioned this issue Feb 1, 2014
Closed
3 tasks
@incanus
Copy link
Contributor Author

incanus commented Feb 1, 2014

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
Copy link
Contributor Author

incanus commented Feb 1, 2014

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

@incanus
Copy link
Contributor Author

incanus commented Feb 1, 2014

Oh yeah, this is gonna work great. Done.

sudo npm install ios-sim -g

@springmeyer
Copy link
Contributor

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

@incanus
Copy link
Contributor Author

incanus commented Feb 1, 2014

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
Copy link
Contributor Author

incanus commented Feb 3, 2014

Beyond this; blocking on libpng Gyp failure now.

@incanus
Copy link
Contributor Author

incanus commented Feb 3, 2014

@incanus
Copy link
Contributor Author

incanus commented Feb 4, 2014

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
Copy link
Contributor Author

incanus commented Feb 4, 2014

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
Copy link
Contributor

I've documented in the readme in 8b4b91f. 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
Copy link
Contributor

kkaefer commented Feb 4, 2014

@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
Copy link
Contributor Author

incanus commented Feb 4, 2014

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
Copy link
Contributor Author

incanus commented Feb 4, 2014

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
Copy link
Contributor Author

incanus commented Feb 4, 2014

@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
Copy link
Contributor

kkaefer commented Feb 4, 2014

@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
Copy link
Contributor Author

incanus commented Feb 4, 2014

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
Copy link
Contributor Author

incanus commented Feb 4, 2014

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
Copy link
Contributor

kkaefer commented Feb 4, 2014

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

@incanus
Copy link
Contributor Author

incanus commented Feb 4, 2014

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 added a commit that referenced this issue Feb 4, 2014
@incanus
Copy link
Contributor Author

incanus commented Feb 4, 2014

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: mapnik/mapnik-packaging#119

@incanus incanus closed this as completed Feb 4, 2014
@springmeyer
Copy link
Contributor

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
Copy link
Contributor

kkaefer commented Feb 5, 2014

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
Copy link
Contributor

kkaefer commented Feb 5, 2014

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

This was referenced Aug 14, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants