The tests create long paths when they see that the Registry value for long path support is set, and the manifest is supposed to advertise that the executable supports long paths. However, when the Registry value is set, the tests fail whether the manifest is embedded or not.
I'm not sure if that's an issue with Wine, MinGW or what I've done.
Some tests have been updated because UTF-8 is used as the native
path encoding with MinGW/Wine, unlike MSVC/Windows.
Some of the tests fail:
- 4 Rust tests fail because long paths are not enabled and so the
paths used when creating symlinks and junction paths are too
long. I've tested them with x86_64-pc-windows-gnu and
x86_64-pc-windows-gnullvm, and both see the same behaviour. The
tests pass when the MinGW-built executable is run on Windows, so
this is a Wine limitation.
- 12 C++ tests fail because directory symlink creation is not
implemented. They fail whether the MinGW-built executable is run
in Wine or on Windows, so this is a MinGW limitation.
- 1 C++ filesystem test fails because long paths are not enabled.
The failing tests are skipped at runtime when built with MinGW,
aside from the one test for long paths being enabled, which expects
them to be disabled when built with MinGW.
If long paths are enabled, e.g. by running
wine reg add HKLM\\System\\CurrentControlSet\\Control\\Filesystem /v LongPathsEnabled /t REG_DWORD /d 1 /f
then many more tests fail because the C++ tests create long paths
when that Registry value is set, but it doesn't seem to actually
enable long path support in Wine, so various filesystem operations
fail.
It includes new functionality that is required for the metadata syntax v0.29.
Add a couple of tests that rely on that new functionality so that the
dependency is backed by tests that fail if it's not met.
Some functionality is only supported because the regex is built with the
Unicode flag instead of the UnicodeSets flag, but that's done for
backwards compatibility as the latter disallows some syntax that may be
in use.
It shows up when using libloot as a FetchContent dependency, and it's a bit confusing to have libloot and libloot-cpp-build when the latter isn't the one that a C++ project should really depend on.
libloot-cargo may still be confusing, but at least indicates what is involved.
Oliver Hamlet
Oliver HamletandGitHub
dependabot[bot]andGitHub