Using the Flex Compiler SHell (FCSH)

18 Jan 2011 – Luke Bayes

What the sHell?

MXMLC and COMPC, when run by themselves, are slow. Not a little slow, not kind of slow – but brutally, soul-crushingly, terribly SLOW. At least that’s how they feel to someone like me. Someone that suffers from chronic, advanced, impatience.

Fortunately, there is finally relief!



Sprouts Shell courtesy of Mike Epp and the Creative Commons license.

What is that at the end of this long, dark tunnel?

More than a few years ago, someone at Macrodobe realized how slow their compilers are, and released the inappropriately-named, yet awesomely helpful, “Flex Compiler SHell” (or FCSH for short). FCSH doesn’t necesarily have anything to do with the Flex framework, but provides a long-lived process that we can start up once, leave running, and ask to execute our compilation tasks. This process will retain lots of expensive information in memory and only recompile files that have changed since the last request. Using FCSH by hand is really not practical, and with previous versions of Sprouts, it was also not as easy as it should be.

I do believe that is a light!

After many, countless hours of deliberation and coding and testing and coding again, FCSH is finally exposed to Sprout projects in a very simple way:

1) In a new terminal, start the fcsh service.

# cd into your project:
cd ~/SomeProject
# Start the fcsh session:
rake fcsh:start

(Hit CTRL+C any time to terminate this FCSH process)

2) In another new terminal (I use GNU Screen thanks to a smart guy I work with), execute the fcsh task before any mxmlc or compc tasks that you would normally call.

# cd into your project:
cd ~/SomeProject
# Compile and run tests:
rake fcsh test
# or the 'default' task:
rake fcsh default
# or clean first:
rake clean fcsh test

That’s it!

Just run the fcsh task before any other tasks, no editing of source files necessary!

But how does it really work?

I’m so glad you asked!

Under the covers, in the latest release of the flashsdk, the mxmlc and compc tasks check for a couple of environment variables before actually calling out to the underlying process.

If the USE_FCSH environment variable value is ‘true’, then the compiler will attempt to connect to an FCSHSocket on FCSH_PORT (12321 by default). The fcsh task simply sets this value to ‘true’, but you can also set this value on the command line, like:

rake test USE_FCSH=true

In your .bashrc or .bash_profile (will impact all Sprout v1.x projects on your system):

export USE_FCSH=true

Or in your Rakefile to always use FCSH for this project:

# Yes, it's a smelly string, but that's what Ruby wants for some reason...
ENV['USE_FCSH'] = 'true'

Regardless of which method you choose to trigger a build with FCSH, you must have an instance of the FCSH server running from the same project directory before calling the build task, or else you’ll get a failure. Once again, you can start the FCSH server with:

rake fcsh:start

If you forget this mysterious incantation, you can always list out the available rake tasks with the -T option:

rake -T

The Railroad

If you want to run builds with FCSH from multiple directories, you’ll need to give each client and server a unique port to connect on. You can do this in any of the ways indicated above for the USE_FCSH parameter, except you’ll specify the FCSH_PORT instead.

On the command line:

rake fcsh test FCSH_PORT=12567

In each shell instance:

export FCSH_PORT=12567

(Note: To always use a custom port, the export could be placed into your .bashrc or .bash_profile)

Anywhere in your Rakefile:

ENV['FCSH_PORT'] = 12567

Conclusion

You should now be able to easily integrate FCSH into your Sprouts v1.x build process at whatever scope you prefer and customize it appropriately too.

This brings us to the end of the “Using the Flex Compiler SHell (FCSH)” post. If you find anything here in error, please let us know, or better yet – fork, fix and send a pull request.