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
>> 
>

Reply via email to