Compiling AS3 quickly

June 24th, 2009

One thing I’ve always missed from my mtasc days is the sheer speed of mtasc. It was almost too fast. Now these days mxmlc provides a similar command line experience, only dirt slow. I suppose Adobe can’t be blamed because it’s due in no small part by Java’s slow startup time, but then again I think I can blame them for that too.

Now, compiling using Flex Builder is faster because the compiler is not unloaded, but it has it’s own problems. In one particular instance I had multiple build targets and experienced even slower speeds than mxmlc alone was capable of. Besides all that, Flex Builder requires a license.

The sole imperfect light on the horizon was fcsh. It only compiles what has changed (crazy! I know!) which makes it extremely fast. The only problem is fcsh is annoying to use and requires that you not leave the program to reap its rewards. There’s also the Flash IDE, and since it’s not really a programmer’s environment, that makes four ways to compile AS3 but no good ways to compile AS3.

Since fcsh has the most promising results I tried to put together a script to manage it, but I couldn’t quite get it to work. Then Ali Rantakari did it with fcshctl. It’s basically what fcsh should’ve been. I’ve had no trouble with multiple build targets, it keeps fcsh running using screen, and the only time it’s ever the slightest bit slow is the first time it compiles something.

So, to save time, I’ve been creating these scripts which make it easy to quickly (re)compile and then launch whatever I’m working on. Here’s an example, which requires fcshctl and flashplayer are in your PATH. If no arguments are given, it will attempt to compile and launch the swf, otherwise it will pass whatever you give it to fcshctl (in case you want to run fcsh commands, like “info”)

if [ -n "$1" ]; then
  fcshctl $@
  fcshctl mxmlc 
  -output deploy/target.swf 
  -compiler.source-path src && 
  flashplayer deploy/mmvsgng.swf

Despite the fact a lot of this should be unnecessary in the end it’s basically my ideal compilation solution — quick, easy, and customizable. I still keep my ant build files around for my non-debug builds, so they still have a purpose too.