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 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.
On Windows using "loot" causes a name collisions with LOOT itself:
- for the MSVC project name, it clashes with LOOT's own project,
despite the difference in case. This means that you can't build LOOT
in Visual Studio when using FetchContent to handle the libloot
dependency (running CMake on the CLI works though).
- for the PDB file, LOOT has LOOT.pdb and libloot has loot.pdb, which
appear to be the same due to file paths being case-insensitive. This
makes it more difficult to debug LOOT with the relevant debug info
loaded.
Renaming the CMake target adds a "lib" prefix to the Visual Studio
project name and the artifact filenames:
- loot.vcxproj* -> libloot.vcxproj*
- loot.dll -> libloot.dll
- loot.lib -> libloot.lib
- loot.pdb -> libloot.pdb
The Linux build artifact filenames are unchanged, as they already had
the "lib" prefix.
When building the first layer of the C++ wrapper, to fix undefined symbol errors when linking libloot as built by Manjaro Linux's default makepkg config.
Instead set their target-specific equivalents.
The POSITION_INDEPENDENT_CODE property isn't set because it already defaults to ON for shared libraries.
So that new warnings don't cause issues for library consumers.
Instead use CMake's CMAKE_COMPILE_WARNING_AS_ERROR option to treat them as errors in CI.
The static library has a static dependency on libloot-cpp that causes more difficulty, and resolving that isn't a priority since I don't use libloot as a static library.
- Use PROJECT_SOURCE_DIR and PROJECT_BUILD_DIR instead of CMAKE_SOURCE_DIR and CMAKE_BUILD_DIR because libloot's CMakeLists.txt may not be the top-level one.
- Specify the working directory when calling cargo
- Define an alias and export the loot target so that it's usable without installing the built artifacts first
Oliver Hamlet