This was done by running `doxygen -u Doxyfile`, using doxygen v1.9.8, as that's the oldest version used in CI, and the latest version (1.16.1) doesn't warn about any other settings being obsolete.
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.
unique_ptr is simpler, and can be easily converted to shared_ptr if needed, and makes it obvious that each call will return a new pointer.
This does mean that if I want to hold onto the objects again in the future for some reason, that'll need the API to change back, but that seems unlikely.
unique_ptr not being copyable does make using it a little more awkward, but that only happened in one place in LOOT's code, and there the pointer needs to become shared anyway.
The C++ wrapper defaults it to true, so the behaviour hasn't changed for
existing callers that don't pass a value for the evaluateConditions
parameter, i.e. that call GetGeneralMessages().
Since the new parameter comes before evaluateConditions,
existing GetGeneralMessages(true) and GetGeneralMessages(false) calls
need to be replaced with GetGeneralMessages(true, true) and
GetGeneralMessages(true, false) to retain their existing behaviour. The
parameter order was chosen to match that of GetPluginMetadata(), at the
cost of this backwards incompatibility.
Oliver Hamlet