-
Notifications
You must be signed in to change notification settings - Fork 1.3k
build iOS runnable app in the style of the OS X one #24
Comments
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. |
Also https://github.com/phonegap/ios-sim comes recommended to me by @landonf, who wrote the original implementation. NPM-installable, too. |
Oh yeah, this is gonna work great. Done.
|
This would be very cool. Didn't even think this was possible. |
Almost building. Looking like this so far: https://gist.github.com/incanus/1ac9408ce885b644d4b4#file-makefile-L31-L34 Error:
|
Beyond this; blocking on |
Latest fail w/
|
As noted by @springmeyer, we need to somehow build |
@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. |
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. |
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?) |
@springmeyer working through your Mapnik-based steps now. One note is you now need three arches for device: I'm getting errors trying to write to |
@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. |
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. |
Putting this into a
|
if we link to the core framework in the ios app, our lib will also get smaller |
Ok I got a build working ok. For practicality, does it make sense to include the build scripts used from Here's my calling script that leads to a fat |
Ok, test app is in The Took care of |
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. |
I'm still getting "building for iOS Simulator, but linking against dylib built for MacOSX file '/opt/X11/lib/libpng15.dylib' for architecture i386" |
Ah sorry, I didn't run the ios setup script. |
Ideally launchable from the command-line, but that might be pushing our luck with the simulator. This builds on #21 switch to Gyp.
The text was updated successfully, but these errors were encountered: