Corona SDK – build automation

In my experience, Corona SDK build process has been a source of pain. It feels like it has been an afterthought thrown in on top of the authorization and remote build system. For those that don’t know, building the code takes place on Ansca’s servers and the process follows something along the lines of:

  1. Edit and save the source files
  2. Launch or keep the Corona simulator open
  3. Go to File -> Build -> Android (or press , Cmd + shift + b)
  4. Fill in Application name, Version, Package, Keystore, Key alias and save path settings
  5. Press build button

Repeat builds do save some time by remembering typed in values, but it’s a far cry from a one click build I would like have. Ideally, the application should be launched on the device at the end of the sequence.

To achieve this, I had to resort to using SikuliGUI automation and little bit of Python scripting. Following gist contains the code: https://gist.github.com/1257755 . Variables in the beginning point to the location of your project, terminal application and so on. Application specific data like name and version should be set there as well. The script will use Android adb tool to install and run the application at the end.

Paths inside the script are OSX specific, but changing them to work on Windows should be very easy.

What you will need: Python, Sikuli and the above gist. Here is a ready zip archive of the script and screen captures required to make it work: http://bayfiles.com/file/1613/LFNkUY/corona.skl

Here it is in action building the sample Clock application:

 

Corona SDK – build automation from Arek Bochinski on Vimeo.

CSC209 – build . a simple make-like tool

Assignment 1 for CSC209 course at University of Toronto in Software Tools and Systems Programming

Build

In this assignment a student is required to write a program in Bourne shell that performs some of the same operations that make does . A simpler file format for a build file is specified , which does not follow all rules of the make program .

Build file format

There are 4 types of valid lines in a build file:

  1. A blank line. I.e., a line containing nothing but whitespace.
  2. A line whose first character is # which indicates that the remainder of the line is a comment.
  3. A line whose first character is an @ followed by a space, and then followed by one or more words separated by a single space. This type of line marks the beginning of a build rule. The @ is ignored. The first word in the sequence is the target of the rule, and the remaining words, if any, are the prerequisites for the rule.
  4. Other lines are considered action lines which should be executable statements.

In example:
#Comment line
@target prerequisite1 prerequisite2
action
action with arguments

Functionality and Implementation

build program will take one or two arguments. The first argument is the target that you want to build. The second argument is the name of the build file to the program will read. If the second argument is not present, the program will try to read a file in the current working directory called buildfile.

Steps:

  1. Read the build file looking for the appropriate rule. If found:
  2. Update prerequisites. (as with make, each prerequisite corresponds to a target in the buildfile, so we might need to execute another rule to ensure that a prerequisite is up to date.)
  3. If the target is a file and has been modified more recently than all of its prerequisites, then the actions are not executed.
  4. If the target is not a file, or any of the prerequisites are newer than the target, then the rule’s actions are executed.

Exceptions:

  • If a rule has no prerequisites, then the rule will always be executed when it is encountered. Note that this differs from make where a rule with no prerequisites is only executed if it is called explicitly.
  • You don’t need to handle recursive targets and prerequisites.

The build process will likely want to call the build program from within the build program. (Recursion comes in many forms.) The best way to do this is to make sure that build is in a directory in the PATH variable.

Testing

Another obvious use for shell scripts is to automate testing programs. We will also write a shell script called testbuild that will run several tests of the build program.

The testbuild program will run at least 3 different test cases that test different parts of the program. We will also need to include one or more build files and possibly some other files. The touch (see “man touch”) command will come in quite handy when we want to change a file’s modification time automatically.

Zip archive can be obtained here: http://zenebo.com/csc209a1.zip