The Flex Compiler Shell Daemon

Some days ago I created a project on Google Code Hosting: the Flex Compiler Shell Daemon, or fcshd for short.

It is a wrapper around Adobe's fcsh, which gives you back the good thing about mxmlc: it's a simple and traditional command line compiler, which compiles your code and returns back an status code telling you if the compilation was successful or not. This may sound old-fashioned in the current shiny-powerful-and-bloated IDE times, but if you are a hardcore IDE person, you aren't interested in mxmlc nor in fcsh anyway.

If you are interested on mxmlc and fcsh, it's because you either don't like the Flex Builder, or because you realized that calling the IDE from your automated build system is not an option. I'm in both camps: Flex Builder is quite buggy in Linux (admittedly it is marked as an alpha release, but come on, it has been in such state for more than a year now!), and I obviously love continuous integration systems and fully automated build scripts.

Back to where I started: Fortunately Adobe released a command-line flex compiler, in the form of mxmlc, for people like me. Unfortunately, it is painfully slow. That's because its startup time is really bad.

Fortunately, Adobe realized this and released fcsh, which compiles your code and don't throw the precious data away by exiting after finishing. It keeps running, waiting for you to tell it when you want to run the same compilation again. Unfortunately, that doesn't work well for build scripts. Wait, I'm wrong. It doesn't work at all.

Fcshd is my humble solution: a simple wrapper written in Python, which spawns a daemonized fcsh wrapper, and calls it when ran from the command line. Yeah, the typical client/server sort of thing. So the client (which is invoked from the command line) can exit after the server has finished the compilation, while the server can keep the data around in memory. As an extra nicety all comes packaged in the same program, which almost always acts as the client, but if it detects that the server is not running then it forks the server. So you use it like this:

$ fcshd.py "mxmlc /path/to/foo.mxml -o /path/to/foo.swf"
Starting the server, please wait... OK
 Loading configuration file [...]
[...]
/path/to/foo.swf (349854 bytes)
(fcsh)

$ fcshd.py "mxmlc /path/to/foo.mxml -o /path/to/foo.swf"
 Loading configuration file [...]
Nothing has changed since the last compile. Skip...
/path/to/foo.swf (349854 bytes)
(fcsh)

Final result: You get your compiler output and status code back, while at the same time it runs blazingly fast.

Right now it is only tested with the Flex 2 SDK, but if it doesn't work with Flex 3, it should be really easy to fix that. It surely have a couple of bugs too, which I haven't found yet. Reports and patches are welcomed!