Haxe macro build order

Hej !

I’m sorry I must be tired but haven’t found anything on the net that could help me even if I think it’s a trivial question.

I know that build macro order isn’t specified so my first question is : even if I have a hub for all my build macros in order to “order” them, how to deal with 3rd party libs that don’t use my hub, how to do my builds run after all that 3rd party build macros please ?

Then my second question is : Can the build macro order do that when I try to get fields of a class (t.get().fields.get()), let’s say in the current processed class, I get a type of a field and I try to get the instance fields of that type, it gives me empty array ? And how to prevent that please or get the fields another way ?

Thanks for your enlighten

Another question that I have is while I understand types building order is unspecified, why the build macro order is also unspecified ? I mean just the @:build and @:autoBuild metas order/position ?
For example if on a type I have several @:build metas, I can see that the first positionned one isn’t always executed first.

Extending that question is, putting init macros, that add @:build and @:autoBuild metas on types using addGlobalMetadata, doesn’t ensure that these build macros will be executed in the order they where added by init macros, while init macros are, what I have seen, executed in the right order (the position they have in the build .hxml file).

And at the end, the thing I thought I could do in order to reorder all build macros was defining an init macro put in the right position that will add @:build on all types using addGlobalMetadata, so this build macro would be executed first, and for all @:buildmetadata on the types, remove them and “inline” execute all the build functions they were supposed to execute, in a specific order : so it would be reordered as wanted.
But here also, I’ve seen that removing @:buildmetadata on the types kind of doesn’t work and these builds are still executed as if they where yet added into a kind of stack, I don’t know…

I’m sure I lack knowledge here and this kind of thinking was too naive ?

I’m afraid I can’t help much, unless you’re willing to rethink your code. What are you trying to accomplish with your macros? Perhaps we could find another implementation that doesn’t rely on execution order?

Thanks for your answer.
In fact, I’ve resolved my problem but I still have these question pending just by curiosity, I would know for example why the build macros are not executed in the order the meta are written…

Well, after few experimentations it seems that I was yelling for nothing…
The types build order is unspecified BUT when a type is built, the @:build macros are applied in order they where written/added, so there is no more problem here.
So, in the .hxml file, if you add at the top a init macro that “manages” others build macros, it will be ok.
(And my misunderstanding came from that I also use libs -lib in the .hxml file that had also init macro that put a @:build meta, so they were executed before my init macro in the .hxml file… I d’ont know if my explanation is clear…)
So just in case somebody understand what I’m talking about can confirm me that the build macros are applied in order they are put please ?

Yup, you’re correct about the order.

It’s best to avoid inspecting other classes from a build macro, let alone an init macro. Whether or not that’s possible of course depends a lot on the use case :wink:

1 Like