Originally, we forced compilation on x86, presumably because at the time HashLink lacked good 64-bit support. When this support improved, the line was changed to force x64 compilation rather than being removed, which may have been a mistake. Now that there are even more valid architectures, it just doesn't make sense to force one.
The old logic could produce inappropriate results, such as attempting to compile an x86 binary on ARM64, or compiling no binary when "64" is specified on a 32-bit machine. I'd argue that it makes sense to only check the flags when they're supported, and not to bother otherwise.
If you check `paths.exists()` first, then there's no benefit to calling `getPath(id)`: it always just returns `paths.get(id)`. It's more effective to let `getPath()` perform all of its checks.
See pull request for details. Summary:
* Reduce dependencies between CI jobs, allowing more of them to run in parallel.
* Use Linux for as many jobs as possible.
* Merge matching "-ndll" and "-samples" jobs. This way, the latter doesn't have to waste time recreating the former's environment, and the workflow summary is simplified. Downside: this delays package-haxelib.
* Update to a newer macOS version, as the old version massively slowed down Homebrew.
* Skip the HelloWorld test for Mac and iOS, as those two can build slowly under some circumstances, delaying package-haxelib. These could be restored later, if performance seems good enough.
* Add `HAXE_VERSION` environment variable, so future updates will only have to make one change. Unfortunately, doing the same for the Windows/Mac/Linux versions would severely hurt performance, so those remain hard-coded.
* Split up some steps within jobs for better organization.
Fixes the following exception when we don't have permissions:
> Failed to execute 'getGamepads' on 'Navigator': Access to the feature "gamepad" is disallowed by permissions policy.
By catching the exception, it should now behave the same as older browsers, where navigator.getGamepads() doesn't exist at all.
In the future, it might make sense to set a flag if navigator.getGamepads() throws, and skip calling it more than once. However, we may want to listen for some kind of browser event that indicates that permission was granted later, and clear the flag when appropriate. Perhaps the gamepadconnected event?
---------
Co-authored-by: Josh Tynjala <joshtynjala@bowlerhat.dev>
Multiplying `dataLength * 8` produces a high number, which in the case of very long audio files can exceed the integer limit. Multiplying by 8.0 coerces to float, allowing much higher values.
An alternate solution is to divide first and multiply by 8 second, thus keeping the number from getting too large at any point. However, the purpose of the 8 is to convert `dataLength` from bytes to bits, so it's clearer if those two are close together.
