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.
Instead set their target-specific equivalents.
The POSITION_INDEPENDENT_CODE property isn't set because it already defaults to ON for shared libraries.
Long paths can be greater than 260 characters long, but each path component is still limited to 255 characters. The latter is also commonly the component length limit on Linux.
Support for long paths requires Windows 10 1607 or later and a Registry value to be set[1], so to make the cause of test failures clearer when that isn't the case, there's one test that checks that Registry value is set, and long paths are not used in the other tests if it isn't set, so only that one test should failed if the system isn't configured as expected.
GitHub Action's Windows runners do have the Registry value set[2].
This doesn't set the manifest for the Rust tests because it seems to be very difficult to set a manifest for only the tests, and it's not worth the effort when the only tests that fail are those that try to create a symlink, especially since those cases are also covered by the C++ tests.
[1]: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry#enable-long-paths-in-windows-10-version-1607-and-later
[2]: https://github.com/actions/runner-images/blob/releases/win22/20250921/images/windows/scripts/build/Configure-BaseImage.ps1#L73
- 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