I like this solution to platform scripts, the only addition I would add is that if the platform allows multiple targets, perhaps it could be possible to set a default one that would be used instead of the timeout to first one (although I suppose that makes first entry inherent default).
Sent from my BlackBerry 10 smartphone. From: Benn Mapes Sent: Friday, March 22, 2013 6:57 PM To: dev@cordova.apache.org Reply To: dev@cordova.apache.org Subject: Re: Platform-level command line scripts ;) +1 I think that would be a good place for the check_reqs script On Fri, Mar 22, 2013 at 3:50 PM, Filip Maj <f...@adobe.com> wrote: > One more addition: based on responses from the cordova-cli threads, it > looks like we'll also add a `check_reqs` script to each platform (perhaps > under /cordova/lib) > > On 3/22/13 3:10 PM, "Michael Wolf" <michael.w...@cynergy.com> wrote: > > >I like this. > > > >mw > > > >On 3/22/13 6:03 PM, "Brian LeRoux" <b...@brian.io> wrote: > > > >>YES. Do it. > >> > >>On Fri, Mar 22, 2013 at 2:38 PM, Filip Maj <f...@adobe.com> wrote: > >>> Hai gaiz! > >>> > >>> Main contention between the two "camps" in this debate is four vs eight > >>> scripts.. But Brian points out that refactoring smaller bits of > >>> functionality into their own script allows us to "have our cake and eat > >>>it > >>> too". This, in turn, results in four + (a subset of the 8) = 10 scripts > >>>in > >>> total.. Which is an argument for just starting with smaller more > >>>discrete > >>> scripts to begin with, lol. > >>> > >>> How about this as a middle ground: > >>> > >>> - under /cordova/ we have the four scripts Anis/Andrew recommend: > >>>clean, > >>> log, build and run. These call into various scripts under cordova/lib, > >>> such as.. > >>> - under /cordova/lib we have the ~6 scripts I recommended: build-debug, > >>> build-release, start-emulator, deploy-device, deploy-emulator, and > >>> possibly a list-devices one as well. > >>> > >>> The final point is nailing what `run` does, step-by-step. Paraphrasing > >>> Anis: > >>> > >>> If device(s) connected: > >>> * Pick device (ignore emulators). > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > >>>devices > >>> are connected (ignore emulators). > >>> > >>> If device(s) not connected: > >>> * Emulator if it is running > >>> * Prompt, timeout and pick first one (5 to 10 seconds) if multiple > >>> emulators are running. > >>> * Start emulator. If you have multiple ones set up (Android's case), > >>> prompt, timeout and launch first one (5 to 10 seconds). > >>> > >>> Yes/no/discuss. Let's try to get to a consensus :) > >>> > >>> > >>> On 3/21/13 5:29 PM, "Brian LeRoux" <b...@brian.io> wrote: > >>> > >>>>I knew you'd bring that up! We'll talk more tmrw. > >>>> > >>>>On Thu, Mar 21, 2013 at 4:40 PM, Anis KADRI <anis.ka...@gmail.com> > >>>>wrote: > >>>>> Šor you can have functions do discrete actions like so: > >>>>> > >>>>> > >>>>> > https://git-wip-us.apache.org/repos/asf?p=cordova-android.git;a=blob;f > >>>>>= > >>>>>bi > >>>>>n/templates/cordova/cordova;h=1945a4c45f835a6eab3836c4154e518b902d88c6 > >>>>>; > >>>>>hb > >>>>>=HEAD > >>>>> > >>>>> Šinstead of creating more inodes. > >>>>> > >>>>> > >>>>> On Thu, Mar 21, 2013 at 4:30 PM, Brian LeRoux <b...@brian.io> wrote: > >>>>> > >>>>>> > You could make more scripts as helper scripts, but I still think > >>>>>>that it > >>>>>> > will be confusing if a user types "ls" and sees a large number of > >>>>>> scripts, > >>>>>> > having to guess what each of them does. > >>>>>> > >>>>>> Put them in a subdir called ./lib and be done w/ it. > >>>>>> > >>>>>> > >>>>>> > I don't think having more scripts will make it more likely that > >>>>>>the > >>>>>> scripts > >>>>>> > will be consistent across platforms. > >>>>>> > >>>>>> Ah, but having smaller responsibilities for a module of code makes > >>>>>>it > >>>>>> more testable in discreet form making it easier to confirm said > >>>>>> suspicions. > >>>>>> > >>> > > > > --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
