OpenFL, as I shared earlier, combines years of development to bring you a fast and stable implementation of the industry-standard Flash development API, free and open-source, ready to provide a backbone for mobile, desktop and web projects.
How does it work? At first, it may seem to be a mystery, but I know that some of you (most of you?) like knowing how things are put together, so let’s dive into it.
OpenFL begins with a run script. The source is located here:
When you execute “haxelib run openfl” (or run the “openfl” alias for the same command), this script is being executed.
It is similar to a simple boot loader. It is enough to run the full command-line tool script, or it can do some things we need internally during development, such as easily recompiling the command-line tools.
The next step are the full command-line tools. This is handled under the “openfl-tools” project:
By separating the tools into their own project, it means that the tools can be updated (or rolled back) independently from the framework. It also means the tools can be used, potentially, for more projects than just OpenFL. It might also make it simpler to work on the tools (if you are improving them) in isolation, leaving the rest of OpenFL in a stable, release version.
When a project includes either an <include /> or a <haxelib /> tag, the tools also look for an “include.xml” in that target directory. If this file is found, the contents included with the user’s project. This gives the ability to automatically extend what <haxelib name=”openfl” /> means, for example. This is how OpenFL loads its additional libraries:
If you are targeting a native platform (Windows, Mac, Linux, iOS, Android, BlackBerry, webOS, Emscripten) then a library called “openfl-native” is included after “openfl.” The “openfl” library includes classes that act more like headers. They define the code completion for the API, but they do not have an implementation. “openfl-native” is the implementation for native targets.
The “include.xml” for “openfl-native” includes a few things:
It includes some native dependency libraries, as well as a template path.
During the build process, the command-line tools look for (and populate) a few different kinds of template files. This based on the target platform, but in general they are Haxe compile scripts, a little of boot code for projects, as well as platform specifics, such as application manifests, meta-data, or in some cases, template projects (such as in Xcode)
These paths cascade, so multiple projects (including your own) can include a template path, in order to override the content of these files. All of these files are processed as Haxe templates, which allows variable expansion, such as “::WIN_WIDTH::” becoming “800” after the file is copied.
Similar to “openfl-native”, the “openfl-html5″ library also includes a template path, defining the “index.html” and other supporting files for running in the browser.