Running Script Before Building?

Hi All,
 
I have written a small windows batch file that creates a file ‘version.lua’ which includes, among other things, a string variable with the current time stamp. This file is ‘required’ into my project and enables me to display build information at runtime. Now I’m looking for a simple way to automatically run this batch file and update version.lua every time I build my app.

I know I can add
  “C:\path\to\Corona Simulator.exe” main.lua
to my batch file and then run the whole thing outside of Lua Glider but I would like an integrated solution.
 
I searched the web and these forums bould couldn’t find a solution - any ideas?

Thanks a lot!
 

Hi All,
 
I have written a small windows batch file that creates a file ‘version.lua’ which includes, among other things, a string variable with the current time stamp. This file is ‘required’ into my project and enables me to display build information at runtime. Now I’m looking for a simple way to automatically run this batch file and update version.lua every time I build my app.

I know I can add
  “C:\path\to\Corona Simulator.exe” main.lua
to my batch file and then run the whole thing outside of Lua Glider but I would like an integrated solution.
 
I searched the web and these forums bould couldn’t find a solution - any ideas?

Thanks a lot!
 

Before starting to use CoronaSDK I used Titanium from Appcellerator and I wrote the same kind of thing for their build scripts. To be honest, it’s about the only thing I miss from Titanium. Lol. Corona seems to be using Ant to build the binaries. If that’s the case it might be possible for the developers to include a tag in build.settings where we could call an external script. Given the power of Ant, it might even be possible to implement something like that purely using the Ant api. 

Hi All,
 
I have written a small windows batch file that creates a file ‘version.lua’ which includes, among other things, a string variable with the current time stamp. This file is ‘required’ into my project and enables me to display build information at runtime. Now I’m looking for a simple way to automatically run this batch file and update version.lua every time I build my app.

I know I can add
  “C:\path\to\Corona Simulator.exe” main.lua
to my batch file and then run the whole thing outside of Lua Glider but I would like an integrated solution.
 
I searched the web and these forums bould couldn’t find a solution - any ideas?

Thanks a lot!
 

Before starting to use CoronaSDK I used Titanium from Appcellerator and I wrote the same kind of thing for their build scripts. To be honest, it’s about the only thing I miss from Titanium. Lol. Corona seems to be using Ant to build the binaries. If that’s the case it might be possible for the developers to include a tag in build.settings where we could call an external script. Given the power of Ant, it might even be possible to implement something like that purely using the Ant api. 

@All,

Glider 1.9 will introduce a plugin system that will allow you to create plugins that lets you perform operations at various locations in the build process. Here is the list of functions we are proposing, if you can think of any other phase of the build process you want to plug into, let us know.

  • preBuildRelease - This happens right after you click the build button and right before the files are getting copied.
  • postBuildRelease - This happens right after the files are finished copying
  • preBuildDebug - This happens right after you click the debug/run button and right before the files are getting copied.
  • postBuildDebug - This happens right after the files are finished copying
  • getLaunchCommandDebug - this gets the command required to launch the sdk
  • getLaunchCommandRelease - this gets the command required to launch the sdk
  • SDKPostLaunch - this happens right after the SDK command line is invoked
  • SDKClosing - this occurs right after the stop button is pressed
  • SDKConnectionMade - this occurs when a TCP connection is made to the debugger.

Each of those functions have 1 argument that has a table containing:

  • Plugin specific options
  • Plugin directory - allows you to bundle executable stuff with a plugin and run them
  • Build folder - path pointing to the build folder (the result of the hammer/debug/run buttons)
  • Project folder - path to the original source folder
  • Configuration name - name of the current config being built

Each of the functions can return a response table containing the following (all optional)

  • message- if you want to show something in a balloon in the IDE you can just add it here
  • cmds-  a list of commands to execute. Standard out will be piped to the “plugins output” tab of the output folder. This is for your convenience, you can just call os.execute(… too.
  • workingDir- the working directory of the command line process

If you can think of anything else please let us know.

Regards,
M.Y. Developers

@All,

Glider 1.9 will introduce a plugin system that will allow you to create plugins that lets you perform operations at various locations in the build process. Here is the list of functions we are proposing, if you can think of any other phase of the build process you want to plug into, let us know.

  • preBuildRelease - This happens right after you click the build button and right before the files are getting copied.
  • postBuildRelease - This happens right after the files are finished copying
  • preBuildDebug - This happens right after you click the debug/run button and right before the files are getting copied.
  • postBuildDebug - This happens right after the files are finished copying
  • getLaunchCommandDebug - this gets the command required to launch the sdk
  • getLaunchCommandRelease - this gets the command required to launch the sdk
  • SDKPostLaunch - this happens right after the SDK command line is invoked
  • SDKClosing - this occurs right after the stop button is pressed
  • SDKConnectionMade - this occurs when a TCP connection is made to the debugger.

Each of those functions have 1 argument that has a table containing:

  • Plugin specific options
  • Plugin directory - allows you to bundle executable stuff with a plugin and run them
  • Build folder - path pointing to the build folder (the result of the hammer/debug/run buttons)
  • Project folder - path to the original source folder
  • Configuration name - name of the current config being built

Each of the functions can return a response table containing the following (all optional)

  • message- if you want to show something in a balloon in the IDE you can just add it here
  • cmds-  a list of commands to execute. Standard out will be piped to the “plugins output” tab of the output folder. This is for your convenience, you can just call os.execute(… too.
  • workingDir- the working directory of the command line process

If you can think of anything else please let us know.

Regards,
M.Y. Developers