Previously, a compiled .app file for HL/C wouldn't launch at all because it couldn't find these libraries. For HL/JIT, it would launch, but it might crash later when it needed to load a missing library.
We need to bundle these dependencies into the .app file so that it can successfully launch on systems that don't have Homebrew installed, or haven't separately installed the exact set of Homebrew libraries that we need. We also don't want to have to make people ask their users to install Homebrew and to install the dependencies manually.
Tested the .app files for both HL/JIT and HL/C on a system without Homebrew. It failed before, but now it launches successfully!
This way, the 8.2.0-Dev version of `PlatformSetup` will have the same indentation as the version on the develop branch. Without matching indentation, Git actively hinders the merging process.
This allows non-simulator builds on CI servers without setting up team-id/provisioning-profile/etc.
It also allows signing using a different method, if desired.
Co-Authored-By: mcagabe19@users.noreply.github.com
We seem to have been assuming that it was false by default, but in SDL 2, it is true by default (planned to be false in SDL 3, apparently). It can cause weird behavior like IME popups appearing when holding down keys (something commonly done by users playing games, so we don't want that!). We want setTextInputEnabled(true) to happen only when an OpenFL TextField (or anything else that accepts text input) receives focus, and then cleared again when focus is lost.
This does not disable regular keyboard input. It is specifically related to what SDL considers text input, which is different, even if it uses the keyboard.
On ios, we build statically linked executables. This means that if lime uses mbedtls 3, hxcpp is also forced to use it which can cause crashes and other problems, as hxcpp is currently written for 2.28
It was hardcoding VS 2017, but now uses vswhere.exe to find newer Visual Studio versions too.
Newer versions of VS don't actually support UWP JavaScript, though. However, if users have UWP installed in VS, the error message will be clearer about that lack of support.
The `Asset` constructor sets `asset.id` to the asset's path, a sensible default. Of course, if the asset has a name instead of a path, we have to use that instead. Or if the user specified an ID, that's even better.
We just don't want to default to `""`, since then a bunch of assets could have the same ID.
Resolves#1758.
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.
