Windows auto builds inconsistently somehow end up with wrong Doxygen version and fail to build docs
oblivioncth opened this issue · comments
This is certainly one of the most bizarre issues I've ever seen.
Windows autobuilds, at first partially, but now mostly, seem to install Doxygen 1.9.4 correctly as they always have, but then when CMake is run somehow Doxygen 1.9.1 is detected at C:/ProgramData/chocolatey/bin/doxygen.exe. In the instances where 1.9.4 is correctly found, it is located at C:/Program Files/doxygen/bin/doxygen.exe.
The obvious suspect is chocolatey, though initial investigation seems to indicate that nothing has changed with that. The runs that started experiencing this issue were performed right after the previous windows doc fix #34 was merged, which was about a week ago at the time of writing. Some changes appeared to have occurred on that same day with GitHub action runners, which seems like too much of a coincidence, perhaps something with the image changed that is somehow causing this.
There is even a run where the Qt-shared based build finds the right Doxygen version, but the Qt-static based build finds the wrong one:
Qt-shared: https://github.com/oblivioncth/Qx/runs/7014637959?check_suite_focus=true
Qt-static: https://github.com/oblivioncth/Qx/runs/7014638072?check_suite_focus=true
More research needed, but there seems to be a concrete demarcation point:
Build where Doxygen 1.9.4 is correctly made available were ran on the Windows 2022 image 20220614.0, and the builds where 1.9.1 somehow magically appears were all ran on 20220619.1 or later.
The initial inconsistency appears to be due to the fact that some of these builds were running during the deployment of 20220619.1 and not all of GitHub's runner hosts had been updated to that image yet, so some runs were still taking place on the 20220614.0 image.
It isn't documented yet, but very recently 20220626.1 has been used for some runs, and all Windows builds fail to find Doxygen 1.9.4, so it's likely safe to assume all hosted runners have updated to at least 20220619.1
Attempted to force Doxygen 1.9.4 via updated find_package(Doxygen 1.9.4) command, but unfortunately this doesn't work, as the 1.9.1 version is still found and CMake simply errors noting the version in compatible instead.
Ok so it seems that (perhaps only as of 20220619.1) Doxygen 1.9.1 is included as part of mingw at C:\ProgramData\chocolatey\lib\mingw\tools\install\mingw64\bin with a choco shim for it generated by default at C:\ProgramData\chocolatey\bin, which is what is being found.
Not sure why the custom installed version doesn't override this though. Likely because the shim is what is added to the path and is the only thing that CMake's FindDoxygen module picks up, though this still is a bit weird given that the custom version has always been installed to C:\Program Files and was correctly detected before.
CMake issue reported here: https://gitlab.kitware.com/cmake/cmake/-/issues/23692
Will resolve this with a workaround for the time being, but hopefully the above gains traction and a proper fix is implemented.
True fixed merged into CMake master for 3.25.0
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7442
CMake 3.25.0 is now used in GitHub's images so the workaround can be dropped
Switched to 3.25.0 and removed workaround.