So I made a new git branch locally, then ran "munit ct" as in an earlier post. All good.
Now I'm facing new trouble: even the as3 step in test.hxml (the first platform...) is not working with the default example:
...scrollable-area>haxelib run munit t Massive Unit - Copyright 2016 Massive Interactive. Version 2.1.2 haxe -main TestMain -lib munit -lib hamcrest -cp src -cp test -swf-version 11 -cmd lime\ build\ html5 -swf build/as3_test.swf HaxeWrapper.hx:73: 'lime\' is not recognized as an internal or external command, HaxeWrapper.hx:73: operable program or batch file. HaxeWrapper.hx:73: Error: Command failed with error 1 Error: Error compiling hxml for as3 Target as3 ...scrollable-area\build\as3_test.s wf
So, where is it getting this "lime\" from? It looks like, because test.hxml includes this line with spaces in it, that somewhere along the line the spaces get escaped, and then another place along the line, a command interpreter, the escaping doesn't seem to count and the system chokes on the backslash.
Hmm. Well, it could just be because it's old code, which I hadn't at first noticed (openfl-validation is deprecated.) The more recent version of openfl's test.hxml looks a bit different. That's because they're making use of their own "haxelib run openfl" script. Where does that come from? Haxelib's docs say to look for a file named "run.n". It's in openfl's repo root, but it's precompiled. Looking at its changelog, it seems RunScript.hx was modified at the same time, so probably run.n comes from there. But the source doesn't even mention a "build" parameter...so how can test.hxml be calling "haxelib run openfl build html5" or "haxelib run openfl build flash" successfully?
I guess the final line passes on the parameters to haxelib. But haxelib doesn't have a "build" parameter either. So I'm still not quite sure how this functions, exactly.