If you have a `<section if="cpp">` tag in your project.xml, you don't want it to be active just because a system environment variable happens to be named "cpp". You only want it active if actually targeting C++.
Previously, null was propagated, which could lead to confusing errors from arithmetic operations. Now, it is ignored, and a warning is displayed that says where the invalid value can be found.
This is its only use case, so there's no need for an intermediate step of getting the library root. `haxelib path` does return the NDLL folder; the problem with the old implementation of `__findHaxelib()` was it got Lime's source folder instead.
We could fall back to `haxelib path` for very old versions of Haxelib, but most likely even people stuck on Haxe 3 have updated Haxelib.
Also, `haxelib path` gave incorrect results in the first place, so falling back wouldn't do any good.
This is where arm64 homebrew installs `libneko.dylib`. However, it may still be in `/usr/local/lib` if installed via the haxe .pkg installer, so we add both.
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.
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.
