Fix haxelib path fallback functionality on windows

[tobil4sk]

The check on line 134 would never work properly on windows, because the line had a CR character so FileSystem.exists returned false. This meant that if a library was resolved via a name that doesn't exactly match the -D flag set by haxelib (e.g. Hxcpp instead of hxcpp or via an alias), then it would be reported as missing.

The fix can be verified by using haxelib 4.2.0 and running haxelib run hxcpp Build.xml using this Build.xml file:

<xml>
    <echo value="${haxelib:HXCPP}" />
    <target id="default" />
</xml>

Currently it fails with the error:

Error: Could not find haxelib "HXCPP", does it need to be installed?

and with the fix, the path is printed without an error.

The same problem was also fixed in hxp, which uses very similar code: openfl/hxp#34.

[moxie-coder]

I always wondered why this didn’t happen on Haxelib 4.1.1, and this forced me to downgrade back to 4.1.1

[tobil4sk]

The reason is that haxelib used to have buggy behaviour when it came to case sensitivity in library resolution, which has now been fixed. For example, if you had hxcpp installed, you could include it using -lib Hxcpp only on windows, because it has a case insensitive file system. This also meant that it would set -D Hxcpp=4.3.2 instead of -D hxcpp=4.3.2, so #if hxcpp checks would be broken. On systems with case sensitive file systems, it would say Hxcpp is not found.

While this old behaviour was clearly broken, it meant that the -D flag was a reliable way to check if the has been resolved correctly, because it matched the input to haxelib path every time.

In haxelib 4.2.0, the behaviour was fixed across platforms (names are now case insensitive everywhere), and now it always uses the name in haxelib.json as the canonical name which is set in the -D flag. This is what hxcpp and hxp checks to see if the library is present, before falling back to the library path check (which this PR fixes on windows).

Using haxelib.json's name for the -D flag would also affect libraries installed with a different name from what haxelib.json contains, e.g. haxelib git hxcpp-custom https://github.com/HaxeFoundation/hxcpp. Cases like this trigger the fallback mechanism in hxcpp/hxp.