The dead code elimination removes the class import if it doesn’t find the class use in the source code. It’s the case with ‘Type.resolveClass’ (the resolution is made at runtime and not during the compilation).
As you can see in the documentation, you can force keeping the class with: add ‘@keep’ in you class, or use ‘–macro keep()’ in the hxml, or completely disable the DCE with -dce no
I already tried to add the @:keep in all the game-related -SymbolX- classes and import them with the wildcarded import, but the game couldn’t resolve the Class at runtime.
It looks like I still have to list all the imports and that the wildcard is not an option, right?
The StackOverflow answer I linked explains this. @:keep doesn’t matter if the compiler never gets to see the type, which it doesn’t with wildcard imports because they’re lazy.
Ok, so if I put @:keep in the SymbolX classes I should be able to reach them even if the wildcarded import is removed by DCE, right? But it doesn’t work, even if I put both @:keep in the classes and @:keepSub in the super, and disable dce.
This because even if the compiler keeps the classes, without the explicit import it doesn’t know where the classes are located, as they are in a different folder, is this correct?
I would need an active (non-lazy) wildcard, but such an option would be very dangerous in the wrong hands.
public static function init() {
#if (gameName == "A")
haxe.macro.Compiler.include("***.symbols");
#end
}
in the class MyClass where all the imports are made, but I don’t know how to add
--macro MyClass.init()
because the panel Compiler Options → Additional Options in HaxeDevelop does not allow to add anything, and if I add it directly in the .hxproj it ignores and removes it
EDIT: ok, maybe I have found the right way to add the option in the hxproj, but now I am probably setting the wrong relative path…
You only have a .hxproj, no HXML file? Personally I would avoid that, makes you very IDE-dependent and you can’t even easily build from the command line. FD can work with HXML files too.
Well, in the bin/html5/haxe folder there are debug.hxml and release.hxml, I suppose they are imported by the template project, so the base versions must be somewh… here they are
Oh, if it’s an OpenFL project, the .hxproj file is pretty irrelevant. In that case, all the build arguments are in your project.xml. Something like this should work:
<haxeflag name="--macro" value="Macro.init()" />
You should not be editing the hxml files generated by Lime, they will just be overwritten during the next build.
Oh, yes, I mean to inject in the template.
Well, if I can do it in the project.xml it is perfect, but I have the same problem:
how do I specify the path to MyClass.init()?
The source path
<source path="..\..\..\..\Library\Base" />
is the root, but I have to reach MyClass, that is in a subfolder
If I put Macro.hx in the root it works, but I need to add the includes in the specific class to centralize everything.
This really looks like a noob problem… I’m feeling sad