The easy thing to do is download fruitstrap at runtime in the iOS implementation, just like android + blackberry do for commons-codec and any other required libs that we can't "ship" with cordova.
I still see value in having an emulate command that will RUN an emulator. I would like to hear more opinions before we figure out tasks. On 3/19/13 4:39 PM, "Tommy-Carlos Williams" <to...@devgeeks.org> wrote: >I would also like to see iOS's "release" script changed. > >Currently (as Fil said below) it compiles with the profile set to >"Release". However, since it is still building targeting x86 (i.e.: the >iOS Sim, not a device) it is inconsistent with say the Android "release" >script that actually gets you a code signed non-debug APK. > >I would like to see "release" on iOS at the very least have a flag >allowing you to set the arch (say armv7 vs x86) and at the best >generating an ad hoc ready .ipa with the correct arch. > >I know there has been no communication from the Fruitstrap guy, so we are >still at a bit of an impasse wrt having the tooling load the project onto >a device, but the "release" script for iOS should at least do something >comparable or even useful. An iOS Sim build with your "Release" profile >is next to useless, really (unless I am missing something). > >Š and yesŠ this is me putting my hand up to do it if there is consensus / >interest. > >- tommy > >On 20/03/2013, at 9:42 AM, Filip Maj <f...@adobe.com> wrote: > >> Bringing this up once more, hopefully the last time :) >> >> TL;DR: the behavior and naming of the platform-level scripts are still >>not >> 100% lined up. I'd like to fix this and agree with you all on some of >>the >> finer points surrounding this issue. >> >> Benn Mapes, an intern at Adobe, has been working on adding Windows Phone >> support to cordova-cli. It's been a bit of work, but the first step is >>to >> land command line scripts at the Windows Phone project level, which he >>is >> actively working on. With this happening, I want to make sure we have >>our >> base project-level CLI scripts sorted properly. >> >> Additionally, I've been seeing issues filed against the CLI with >> essentially users being confused as to why the behavior of "cordova >>build" >> vs "cordova emulate" on different platforms is different [1] [2]. >> >> The answer to all of this is that the project-level scripts have >>slightly >> different behavior. I've looked into what each of Android, iOS and >> BlackBerry (10) do and I've got a basic table sorted out (below). I >>would >> like to get to an agreement on naming and behavior for each, and ideally >> file issues to get as many of our platform implementations as possible >>to >> implement/tweak behavior so that we are consistent on this front. >> >> Scripts >> ------- >> >> - build >> - Android: equivalent of running `ant debug`, which simply compiles >> your app in debug mode >> - BB10: packages your app into a zip, runs `bbwp` on it, and >>code-signs >> it >> - iOS: runs a compilation with xcodebuild with configuration set to >> "Debug" >> - clean >> - Android: equivalent of running `ant clean`, which removes any build >> artifacts >> - BB10: does not exist >> - iOS: does not exist >> - log >> - Android: `adb logcat` >> - BB10: does not exist >> - iOS: `tail -f console.log` >> - release: >> - Android `ant release`, compiles with your actual signing key >> - BB10: NOPE >> - iOS: compiles with xcodebuild with configuration set to "Release" >> - run: >> - Android: runs on EITHER a connected device, or if no device, on a >> running emulator, or if no running emulator, launches an emulator (and >>if >> multiple emulator profiles exist, prompts user to pick one), then >>finally >> runs the app on it >> - BB10: asks user if there's a connected device. Then either launches >>a >> simulator + loads the app (if user says he/she has no connected device), >> or attempts runs a debug build of the app on a connected device >> - iOS: launches an emulator using ios-sim with the app >> - emulate: >> - Android: does not exist >> - BB10: does not exist >> - iOS: launches an emulator using ios-sim with the app >> >> Easy Wins >> --------- >> >> - build: BB10 should change current behaviour so that it doesn't code >> sign the package. >> - clean: add scripts for BB10 and iOS to support this (should be dead >> simple). >> - release: BB10 should implement a script that runs a build + a >>code-sign >> on the built package. >> >> Harder Wins >> ----------- >> >> There's confusing behavior with run + emulate commands across platforms. >> IMO emulate should handle launching an emulator, and run should handle >> deployment, with an extra flag available for run command that specifies >> the deployment target (device or emulator, perhaps --device and >> --emulator). Also not entirely sure how Ripple fits in here but I would >> definitely like to see Ripple as the default emulator target. >> >> Lots to chew on here but I would highly appreciate some feedback! >>Renaming >> some of these commands is on the table too if anyone sees benefit there! >> >> [1] https://issues.apache.org/jira/browse/CB-2722 >> [2] https://issues.apache.org/jira/browse/CB-2724 >> >
