#if macro
public static function init() {
#if (gameName == "A")
haxe.macro.Compiler.include("***.symbols");
#end
}
#end
Like this? Same problem.
EDIT: it looks like HaxeDevelop is going crazy if I put the init() function in MyClass…
In another class it points to
D:\HaxeToolkit\haxe\lib\openfl\8,9,2\src\openfl\Lib.hx:7: chars 7-27 : Error: referenced here
I wonder what’s the difference of putting the static function in different classes.
EDIT 2 : if I put init() separately in a class parallel to MyClass, let’s say MyClassB, same package, it works! It looks like putting the function in MyClass triggers some really weird conflicts in unpredictable places.
I suspect the problem are the other classes used in the same class, importing them explicitly or implicitly triggers the above conflicts… could this be a bug in the compiler?
Did the class you added the init macro to contain other code too? It’s generally good practice to put macros into completely separate modules, because macro and regular context can easily get mixed up and lead to errors like the ones above.
I tried to clean the code even more and do like this
public static function init() {
var gameName: String = Compiler.getDefine(“gameName”);
haxe.macro.Compiler.include("***." + gameName);
}
so I can simply use these 4 lines for all games, but it tells me
EDIT: I will keep the macro in the separate class, but now I’d like to build the include path by a root and the gameName that I set in each project.xml with
Are you sure it is ignored (you can easily check by putting a trace into it)?
It looks good, but you can check the generated hxml to make sure that it’s indeed added to it.
I don’t know why, but now it works… and the code is exactly the same
Ok, I managed to include everything and I create a .txt containing the list of included files, just to compensate the missing list of explicit imports that I used to add before: I think it is better to check what it includes.
Now, if it were me, I would not use wildcards: I would explicitly name every class that I needed, just as you do in the original (conditional compilation) code. And, here’s why:
(1) It documents what classes are required.
(2) If anything’s not there, compilation will fail … meaningfully.
Otherwise, you can guess what’s gonna happen someday: someone diddles with that include-library folder. And thereby suddenly breaks everything, in a way that’s very hard to diagnose and fix. You can’t look at the source-code to understand the actual requirements, because the source-code does not tell you exactly what’s “in the source code of any particular compile!”
If you take the time to be explicit – “copy and paste” are your friends here – your source code is much easier to desk-check.
P.S. If it’s convenient to have a “text file” of the includes, it’s a trivial matter to write a little script that will generate the necessary Haxe source-code of declarations to be included as a single unit. (You check-in both the generated file, and the script, and the text-file to your version control system.)
“Is there a difference? Yes!” Because, “the decision was made, by someone, the last time that script was run.” Version-control now allows me to diff between the two versions to determine exactly what changed. And, explicit declarations allow me to conclusively determine the extent of the source-code that I now need to research to find that pesky bug. (As long as you took care to also put all of the referenced libraries under version control …) I know that (too bad about that bread-truck, pal …) I can today reproduce your build-environment exactly.
