Expose architecture defines during Project XML parsing

[Tutez64]

Summary

This updates Lime to expose resolved architecture defines earlier, during Project XML parsing.

HXProject now sets architecture-related defines such as:

• HXCPP_M32
• HXCPP_M64
• HXCPP_ARM64
• 32
• 64
• x86_32
• x86_64
• arm64

based on the requested target flags, or the default native architecture when applicable.

Why

Some extensions need to select platform-specific runtime assets from include.xml, but architecture information was only becoming available later during the build phase.

This made conditions like if="HXCPP_M32" unusable in include.xml, even though the final build target was already known.

Result

Extensions can now use normal XML conditions to choose the correct architecture-specific assets during project parsing, without requiring post-build scripts or other workarounds.

[tobil4sk]

I would prefer to avoid exposing the HXCPP_* flags to include.xml, since they are hxcpp specific flags and we don't necessarily know how hxcpp will chose to interpret them or what other extra flags it might set. It also better to have target agnostic flags that are also relevant to other targets like neko, hashlink, etc. Preferably they should also be a bit more descriptive than 32 or 64.

[Tutez64]

I agree, the goal is to expose the target architecture information.
For this, it would be better to expose target-agnostic and descriptive defines such as:

• x86_32
• x86_64
• arm64
• armv7

rather than HXCPP_* or generic 32 / 64.

If that approach sounds good, I can update the PR accordingly.

[tobil4sk]

That does sound better, however, just to let you know because I saw the steamwrap or that you linked. Lime follows a layout in the ndll folder which should allow copying to be handled automatically for every platform, without the include.xml having to do it manually. I would recommend relying on that rather than handling each case individually, that might also avoid the need for these flags. Lime's ndll is handled like this for example.

[Tutez64]

I tested this approach locally.

I placed libsteam_api.so next to steamwrap.ndll in ndll/Linux and ndll/Linux64, removed the manual Linux copy from include.xml, and rebuilt a Linux target.

In the final output, Lime still copied steamwrap.ndll, but it did not copy libsteam_api.so or other companion files placed next to it.

So from what I could reproduce, the standard ndll layout seems to handle selecting the correct ndll, but not automatically packaging additional runtime libraries beside it.

If there is a specific extension or code path that demonstrates the intended behavior, I’d be happy to follow that pattern instead.