Fixed CmdLine Windows Build with command-line (not in VisualStudio but in VSCode)

[blessio]

Autotype-tests (not the keepassxc.exe application itself) could not link any more for Windows after a recent update.

Steps to reproduce (On Windows > 10):

mkdir build
cd build
cmake -DWITH_XC_ALL=ON -DWITH_GUI_TESTS=ON  -DVCPKG_MANIFEST_MODE=ON -DCMAKE_SYSTEM_VERSION="10.0.26100" -DCMAKE_TOOLCHAIN_FILE=c:\vcpkg\scripts\buildsystems\vcpkg.cmake  -DVCPKG_TARGET_TRIPLET=x64-windows -DCMAKE_BUILD_TYPE=RelWithDebInfo ..
cmake --build . --config RelWithDebInfo 

See command here

Expected result is: that the build, which includes build of tests succeeds. Actual result is: several error messages that the linker cannot find WindowsHello needed for keepassxc-autotype-windows. See detailed build here

an excerpt from the error messages is included:

keepassxc_gui.vcxproj -> D:\a\keepassxc-B\keepassxc-B\build\src\RelWithDebInfo\keepassxc_gui.lib
  Automatic MOC and UIC for target keepassxc-autotype-test
  Building Custom Rule D:/a/keepassxc-B/keepassxc-B/src/autotype/test/CMakeLists.txt
  AutoTypeTest.cpp
  mocs_compilation_RelWithDebInfo.cpp
     Creating library D:/a/keepassxc-B/keepassxc-B/build/src/autotype/test/RelWithDebInfo/keepassxc-autotype-test.lib and object D:/a/keepassxc-B/keepassxc-B/build/src/autotype/test/RelWithDebInfo/keepassxc-autotype-test.exp
  keepassxc-autotype-test.vcxproj -> D:\a\keepassxc-B\keepassxc-B\build\src\autotype\test\RelWithDebInfo\keepassxc-autotype-test.dll
  Automatic MOC and UIC for target keepassxc-autotype-windows
  Building Custom Rule D:/a/keepassxc-B/keepassxc-B/src/autotype/windows/CMakeLists.txt
  AutoTypeWindows.cpp
  mocs_compilation_RelWithDebInfo.cpp
     Creating library D:/a/keepassxc-B/keepassxc-B/build/src/autotype/windows/RelWithDebInfo/keepassxc-autotype-windows.lib and object D:/a/keepassxc-B/keepassxc-B/build/src/autotype/windows/RelWithDebInfo/keepassxc-autotype-windows.exp
keepassxc_gui.lib(QuickUnlockInterface.obj) : error LNK2001: unresolved external symbol "public: virtual bool __cdecl WindowsHello::isAvailable(void)const " (?isAvailable@WindowsHello@@UEBA_NXZ) [D:\a\keepassxc-B\keepassxc-B\build\src\autotype\windows\keepassxc-autotype-windows.vcxproj]
keepassxc_gui.lib(QuickUnlockInterface.obj) : error LNK2001: unresolved external symbol "public: virtual class QString __cdecl WindowsHello::errorString(void)const " (?errorString@WindowsHello@@UEBA?AVQString@@XZ) [D:\a\keepassxc-B\keepassxc-B\build\src\autotype\windows\keepassxc-autotype-windows.vcxproj]

This should not happen if one is using Visual Studio (including Visual Studio in a commandline). It happens, though, if one uses pure CMake/MSBuild.

This very PR resolves this issue. Proof: a build with this PR Commit is here.

Note: When I write "resolves the issue" I mean that now it can be built and run on Windowa. That is build and run the "testautotype" test on Windows. Unfortunately, the test itself does not pass on Windows (passes on Linux and on MacOS), but it has been failing in Windows since long time, afaik (will see it in the PR-auto-ci-build). So, this is a separate problem (if at all) for solving.

[droidmonkey]

You shouldn't need to do all this, that is built in CMake capability. I believe you have an error in that you should not be setting CMAKE_SYSTEM_VERSION to the WinSDK version, instead directly set -DCMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION=10.0.26100.0

Also, usually using the Ninja generator -G Ninja is sufficient to overcome MSBuild quirks

[blessio]

Thanks for the prompt reaction.

Indeed, this is not needed:

-DCMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION=10.0.26100.0

It is done by a CI robot ... so it is added each time ... that is why I included it because it is more precise for steps to reproduce and what has happened in case it cannot be reproduced. I am almost sure (and expected) that it is irrelevant for the case.

Indeed, I just tried and removed the above -DCM.... then deleted the build subfolder and recreated it. After rerunning the commands above but without the -DCMAKE_VS_WINDOWS_TARGET_PLATFORM_VERSION in the cmake .. . ==> Result and error messages are the same.

The root-cause is that the standard build in Visual Studio (Community/?Pro?/Enterprise) uses hidden dependencies (ENV variables and setup) which is not there when using a bare command-line - not a Visual Studio Community commanded-line.

Hidden dependencies are not good - right? ...

So, the commit/PR that I suggest, makes the dependency explicit (instead of hidden) that is all.

[droidmonkey]

Ahhh so you aren't running this in a vs devcmd environment? You need to do that instead of hacking in cmake.

See our release tool for example: https://github.com/keepassxreboot/keepassxc/blob/967dc5937f1f69e601f7aecbc600ef9027cc5043/release-tool.py#L295

[blessio]

You need to do that instead of hacking in cmake.

:-) I hope I really do not need to ... it was working (I mean buildind) for almost a year without devcmd ...

Besides, having hidden dependencies is really not good ...

Only an opinion: I will be very grateful if you keep the KeePassXC not hardly dependent VS Community ("benefitting from" is actually good, but "dependent on" on VS-Comunity would be better not).

[droidmonkey]

You can build in MinGW as well. Unfortunately, to gain advantage of the windows SDK you basically need to incorporate visual studio somewhere.

I think your PR is fine. I will do some testing to make sure it doesn't regress anything.

[blessio]

I think your PR is fine. I will do some testing to make sure it doesn't regress anything.

==> sounds like the right way.

In case it helps

In case it helps, here are the unit-tests results runs (on 1.Windows, 2.Linux "latest" and 3.Linux 24.04 (I believe both Linux builds are currently on Ubuntu 24.04), 4.MacOS "latest" and 5.MacOS-13 (old intel x86 silicon)):

• after the change: https://github.com/blessio/keepassxc-B/actions/runs/19786067722
• before the change: https://github.com/blessio/keepassxc-B/actions/runs/19408623742

The detailed run can be seen in the build log as well as in downloads.

the unit-test runs are always in step 750 of all 5 builds above.

Summary of what fails

Summary of what fails is visible in the summary page of each workflow run:

if you want this build PRed in your central repository please let me know :)