haxe 3.4.0 compilation freezing #5918

r3d9u11 opened this Issue Jan 3, 2017 · 4 comments


None yet

4 participants

r3d9u11 commented Jan 3, 2017 edited

Hi. I have some troubles with haxe 3.4.0: when I try to compile openfl project with several compies of one font-file in different folders then compilation process will be freezed.

with haxe 3.2.1 this appliation will be already compiled.

tested OS: Windows 7 x64, Ubuntu 16.04 x64, Linux Mint 18 x64, Linux Mint 18.1 x64

Also this situation was described here: r3d9u11/StablexUI-Designer#1


example: test.zip
will be compiled with haxe 3.2.1, but not with haxe 3.4.0

Simn commented Jan 5, 2017

I can never remember now to compile these things...

jgranick commented Jan 6, 2017

I believe there was some kind of recursion in how the macros were typed since the Haxe 3.4 RC releases, which did not exist in Haxe 3.2.1. By making sure that we do not reference classes that have @:build macros directly (or indirectly) in other macros, we have been able to avoid this issue.

This has been worked around in the latest Lime development builds.

For the record, this is all that is required 😄

haxelib install openfl
haxelib run openfl setup
cd path/to/project
openfl test neko
jgranick commented Jan 6, 2017 edited

I do not have a simple reproduction case, but for reference, the issue is caused by something similar to this:

@:build(CustomMacro.build()) class LimeFont {}
class Font extends LimeFont {}
class Arial extends Font {}
class Tahoma extends Font {}

For some reason, having more than one class that extends openfl.text.Font (which in turn extends lime.text.Font) caused the compiler to hang forever. Only one of these instances and it work properly.

Our workaround was to remove the @:build macro on lime.text.Font

There is an @:autoBuild on lime.text.Font as well, but that's unrelated -- commenting that out would still incur a freeze.

EDIT: If someone wanted to reproduce this using OpenFL, try:

haxelib install openfl
haxelib run openfl setup
openfl create project FreezeTest

Then use something like this for the Main source:

import openfl.display.Sprite;
import openfl.text.Font;

class Main extends Sprite {
    public function new () {
        super ();

class Arial extends Font {
    public function new () { super (); }

class Tahoma extends Font {
    public function new () { super (); }
@Simn Simn added this to the 3.4 milestone Jan 9, 2017
@bendmorris bendmorris referenced this issue in HaxePunk/HaxePunk Jan 9, 2017

Endless compilation loop #434



I've ran into the same issue, but I have no working fix. @jgranick removing the @:build macro in lime.text.Font only makes it so that the CFFI native functions don't have a body, thus not actually compiling (but hey at least it doesn't hang I guess).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment