Yes, this is still maintained, and it’s likely what you want to use. At least for now. When you have more time, by all means try to get an OpenFL-based solution up and running, but it sounds like right now you just need AS3 code based on your Haxe code.
The thing to understand is that Haxe is primarily a source-to-source compiler. That is, Haxe’s main feature is to take Haxe code and produce the equivalent source code in another programming language.
When you run openfl test android, Haxe doesn’t compile the Android app. Haxe just turns your source code into the equivalent C++ code. Then OpenFL passes that C++ code to the Android build tools, and those tools create the actual Android app. Haxe does nothing more than translate Haxe code into C++ code; other tools handle the rest.
You might be wondering why I’m going on and on about this one little thing. All I’m saying is, Haxe has one job*, and it is very good at that job. You can absolutely tell Haxe “convert my Haxe code to AS3 code,” and Haxe will create working code. (It won’t be pretty code, but it will definitely work.)
*Well, one main job. In addition to source-to-source compiling, Haxe can create entire Flash, Neko, and HashLink apps.
So how do you do this? Well, start by opening up the command line and typing “haxe.”
> haxe
Usage : haxe.exe -main <class> [-swf|-js|-neko|-php|-cpp|-cppia|-as3|-cs|-java|-python|-hl|-lua] <output> [options]
Options :
-cp <path> : add a directory to find source files
[...]
-swf <file> : compile code to Flash SWF file
-as3 <directory> : generate AS3 code into target directory
[...]
-main <class> : select startup class
-lib <library[:version]> : use a haxelib library
-D <var[=value]> : define a conditional compilation flag
[...]
It’s a lot to take in, but the short version is that it wants you to provide a main class, an output type and directory, and a class path where it can find your Haxe files.
And you can absolutely do it that way:
> haxe -main com.example.Main -as3 Export/as3 -cp Source
But you’d also have to add a -lib flag for every library you use (including OpenFL), and then define who knows how many compilation flags. Luckily, there is another way.
Since OpenFL uses Haxe, OpenFL has to define all these arguments itself. Fortunately for you, it leaves a record of the arguments it used. Open up your Export/ios folder, and whatever other folder(s) are inside that (at a guess, it might go Export/ios/air/release, but it doesn’t matter if not). When you find a set of three folders named bin/, haxe/, and obj/, you’ll know you’re in the right place.
Open the haxe/ folder and then open release.hxml. (If your computer asks what program to use, pick any text editor.) Notice that release.hxml is one big list of command line arguments for Haxe. Haxe accepts this kind of file instead of actual command line arguments, and release.hxml happens to be set up to make Haxe compile your code correctly (including all libraries and compilation flags).
You only need to make one little change. Near the end of the file should be a line saying something like -swf Export/ios/air/release/bin/AppName.swf. This is the line telling Haxe that the final product is a .swf file, but you can replace it with “-as3 Export/as3,” which tells Haxe that the final product should be AS3 code.
The last step is to run Haxe. Don’t run OpenFL, because it will overwrite your changes. You want to run Haxe directly.
Open up your command line window again, and navigate to the root of your project. You should be in the folder containing project.xml, the Source/ folder, and the Export/ folder. Now you need to type out the path from here to release.hxml, like so:
> haxe Export/ios/air/release/haxe/release.hxml
It’ll take a while, but once it’s done, check under Export/as3 for all of your code in AS3 format.
but I guess it won’t work in my case, it seems to check like a compilator if the code is using method that can be translated or not. I’m using some very openFL / HTML5 specific classes, and it raise error without event try to translate.