Previously, we added these rpaths to lime.ndll when it was built in commits c70ec9f and 333d093, but it's actually necessary only for Neko, so now I made it happen specfically after calling `nekotools boot` to create the Neko executable.
I've tested cpp and hl, and I've confirmed that the executables still launch successfully when these rpaths are omitted. It's better for their security to use fewer rpaths.
As noted commit c70ec9f, adding these rpaths is necessary due to a change in Xcode 15 where /usr/local/lib used to be available on the rpath automatically, but now it isn't, which affects the executable's ability to find the libneko dylib.
* Add Drop file event support for android.
* Updated MIME type configuration and intent filter generation.
* "supportedMimeTypes" => "mimeType"
* `mimeType` -> `accept-file-intent`
The former was unclear about how the dependency would relate to web workers. Would it only be available to workers? Would it automatically spin up a worker?
`allow-web-workers` isn't 100% perfect, but it implies the correct answers to the questions above (no and no) and isn't too long.
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!
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.
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.
Code intelligence should always use the newest hxml content, so the fallback mode where the hxml content is generated, instead of loaded from an existing .hxml file, should be used when the project file is newer.
For instance, if the user changes any file/dir paths in their project file, continuing to use the existing .hxml file could lead to confusing error messages that still reference the old/cached file paths. It should always use the latest paths or other values from the project file. It should be considered a bug to use the old cached paths.
Previously, as a workaround, the user would need to clean or build their project again to get updated .hxml files. It might also require restarting their editor/IDE too. Bad developer experience when we can detect this case automatically.
Now if you need to add something to the `<application />` or `<activity />` tags, you can do it from project.xml. This will require new documentation, however.
