Open alemuntoni opened 2 years ago
Your cmake command looks correct though
I think it would be good to have cmake example in the tests. If you figure out the problem feel free to submit a PR to test cmake :)
I don't have the background to investigate and make fixes in the code unfortunately, but I did find what could be a possible cause. It seems that the action I used to set the MSVC compiler is messing up something (I have to build with MSVC in my projects on windows).
Without setting MSVC, the ccache action works (but of course, MSVC is not set).
The action I use to set MSVC is ilammy/msvc-dev-cmd, which is the most used for this scenario. I see that ccache supports MSVC and should also this action, am I right?
Could it be that cmake skips the compiler launcher for MSVC?
Ccache recently gained Windows support so maybe your version doesn’t support it yet.
Ccache recently gained Windows support so maybe your version doesn’t support it yet.
It seems that the ccache version that default workflows use is 4.3 (which seems that does not support msvc). However it is not clear to me whether ccache is shipped with default github actions runners or it is installed by this action. In the latter case, maybe just installing a newer version could solve this issue!
Update: upgrading is not enough. In this workflow I upgraded to ccache 4.7 (which should support msvc) before using this action. The message error "Not saving cache because no objects are cached" persists.
I also encountered this issue, even with updating ccache to 4.7.1 I got "Not saving cache because no objects are cached" I was however able to get ccache working locally, so the issue seems specific to either the GitHub runners or the ccache action
I used CMake 3.25.0-rc1 locally while the runner used 3.24.2 per the runner readme
I used Ninja 1.11.1 locally, I'm unsure what version of Ninja the runners ship with
Locally I used vcvarsall.bat
on actions I used ilammy/msvc-dev-cmd
Maybe one of those differences is responsible, maybe try updating Ninja like you did with ccache?
Thanks @TheLastRar!!
It seems that it works by updating both ccache to 4.7.2 and ninja to 1.11.1 (see this action)!
I updated them using choco (choco install ccache
and choco install ninja
).
I don't know if these operations could be executed automatically by the ccache-action
, or it would be better to wait that Github runners update ninja and ccache packages..
I've updated ccache for windows to 4.7.2 and created a new release.
Let me know if that helps.
@hendrikmuhs it seems that it is not working :(
See this job.
After using ccache-action@v1.2.4
, printed version of ccache
is still 4.3.
Thanks @alemuntoni,
it looks like your CI image has a conflicting ccache which is taken instead of the one provided by this action. When @jonashaag added ccache for windows, the version was 4.6 afair.
From your logs: C:\ProgramData\Chocolatey\bin\ccache.exe
Chocolatey originates from the github image: https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md
Unfortunately it is in the PATH
before the installed one:
Path: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\bin\HostX64\x64;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\VC\VCPackages;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\bin\Roslyn;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Team Tools\Performance Tools\x64;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Team Tools\Performance Tools;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\Extensions\Microsoft\CodeCoverage.Console;C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\\x64;C:\Program Files (x86)\Windows Kits\10\bin\\x64;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\\MSBuild\Current\Bin\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\Tools\;C:\Program Files\MongoDB\Server\5.0\bin;C:\aliyun-cli;C:\vcpkg;C:\Program Files (x86)\NSIS\;C:\tools\zstd;C:\Program Files\Mercurial\;C:\hostedtoolcache\windows\stack\2.9.1\x64;C:\cabal\bin;C:\\ghcup\bin;C:\tools\ghc-9.4.2\bin;C:\Program Files\dotnet;C:\mysql\bin;C:\Program Files\R\R-4.2.1\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\npm\prefix;C:\hostedtoolcache\windows\go\1.17.13\x64\bin;C:\hostedtoolcache\windows\Python\3.9.13\x64\Scripts;C:\hostedtoolcache\windows\Python\3.9.13\x64;C:\hostedtoolcache\windows\Ruby\3.0.4\x64\bin;C:\tools\kotlinc\bin;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.345-1\x64\bin;C:\Program Files\ImageMagick-7.1.0-Q16-HDRI;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\Program Files\Microsoft\jdk-11.0.12.7-hotspot\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\ProgramData\Chocolatey\bin;C:\Program Files\PowerShell\7\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;C:\Program Files\OpenSSL\bin;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.6\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\nodejs\;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GitHub CLI\;c:\tools\php;C:\SeleniumWebDrivers\ChromeDriver\;C:\SeleniumWebDrivers\EdgeDriver\;C:\Program Files\Amazon\AWSCLIV2\;C:\Program Files\Amazon\SessionManagerPlugin\bin\;C:\Program Files\Amazon\AWSSAMCLI\bin\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\LLVM\bin;C:\Users\runneradmin\.dotnet\tools;C:\Users\runneradmin\.cargo\bin;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps;C:\Program Files (x86)\Microsoft Visual Studio\Installer;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\VC\Linux\bin\ConnectionManagerExe
You can try to fix your PATH.
For this action it would be nice if we can use full qualified paths and detect and warn if such a conflict appears.
Nice debugging! I wonder if we could somehow integrate your test project into this repo.
Why providing a different version of ccache? Wouldn't be possible to use (and update with choco) the one that is already provided by the github image?
Could be the action ilammy/msvc-dev-cmd@v1
that is modifying PATH
in such way? Consider that this action is the most used one to make MSVC compiler the default one...
Feel free to use any of the code in my test action if it is useful to setup a proper test. I don't actually know how actions work internally, therefore I am not the most suitable person to make a PR :)
Why providing a different version of ccache? Wouldn't be possible to use (and update with choco) the one that is already provided by the github image?
I didn't know choco has its own and I don't know if it is meant to be used or if it is an internal tool for choco(does anyone know?). The decision to ship it with the github image is a decision of the github development team, they might change their mind. Not every project uses choco. So long story short, I don't think we should re-use it and apart from that we do not have control over the version. It seems the version isn't usable for us anyway.
I therefore think that "fixing the PATH
" is the best option.
Option 3 would be renaming the binary, but this has a lot of disadvantages, e.g. w.r.t. platform compatibility, so it isn't an option IMO.
Note that I am not developing on windows at the moment, so I don't have the necessary setup to play with. At best I can take your demo-environment as playground. It would be better if someone with a stronger interest and more knowledge about tooling on windows has a look. I happily take and merge PR's.
This problem also occurs, when ccache is called and works properly. This example has 269 cached objects, consuming 17.2 MiB, but the action doesn't archive them.
Post job cleanup.
ccache stats
C:\ProgramData\Chocolatey\bin\ccache.exe -s
cache directory C:\Users\runneradmin\AppData\Roaming/ccache
primary config C:\Users\runneradmin\AppData\Roaming/ccache/ccache.conf
secondary config (readonly) R:/winlibs64_stage/inst_ccache-4.3/etc/ccache.conf
stats updated 03/03/23 14:16:46
cache hit (direct) 0
cache hit (preprocessed) 0
cache miss 135
cache hit rate 0.00 %
cleanups performed 0
files in cache 269
cache size 17.2 MB
max cache size 5.0 GB
Not saving cache because no objects are cached.
So what should we do if I want msvc+debug+ninja+ccache in window server 2022 in github workflow runner. give a issue for github?
I can compile in this way , bug at the end of CI, it tell me no objects are cached.
choco upgrade ccache ninja
worked for me.
Hopefully Github can upgrade their windows-latest
runners with new ccache
and ninja
versions soon.
This issue still affects me when compiling with MSYS2 and MinGW.
Hi all, so I stumbled onto this issue trying to get MSVC/CL working with this CCACHE action on windows-latest
workers. I found that it seemingly cached release builds without any issues:
Post job cleanup.
ccache stats
C:\ProgramData\Chocolatey\bin\ccache.exe -s
Cacheable calls: 10[2](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:2)9 / 1029 (100.0%)
Hits: 0 / 1029 ( 0.00%)
Direct: 0
Preprocessed: 0
Misses: 1029 / 1029 (100.0%)
Local storage:
Cache size (GB): 0.1 / 0.5 (18.46%)
Hits: 0 / 1029 ( 0.00%)
Misses: 1029 / 1029 (100.0%)
Save cache using key "ccache-ccache-windows-release-202[3](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:3)-12-31T07:59:31.8[4](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:4)7Z".
"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tzst --exclude cache.tzst -P -C D:/a/godot-orchestrator/godot-orchestrator --files-from manifest.txt --force-local --use-compress-program "zstd -T0"
Cache Size: ~83 MB (8692[5](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:5)24[6](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:6) B)
Cache saved successfully
But for Debug builds, it refused to cache anything:
Post job cleanup.
ccache stats
C:\ProgramData\Chocolatey\bin\ccache.exe -s
Cacheable calls: 0 / 10[2](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201385#step:27:2)9 ( 0.00%)
Hits: 0
Direct: 0
Preprocessed: 0
Misses: 0
Uncacheable calls: 1029 / 1029 (100.0%)
Local storage:
Cache size (GB): 0.0 / 0.[5](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201385#step:27:5) ( 0.00%)
Not saving cache because no objects are cached.
The cmake builds are identical other than specifying debug vs release. The job insures that both ccache and ninja are the latest, of the above run the versions are:
ccache v4.8.3 is the latest version available based on your source(s).
ninja v1.11.1 is the latest version available based on your source(s).
In case this is helpful, the debug configuration is as follows:
Build Configuration
CMAKE_SYSTEM_PROCESSOR:..................: AMD64
CMAKE_HOST_SYSTEM_NAME:..................: Windows
CMAKE_BUILD_TYPE:........................: Debug
CMAKE_CXX_COMPILER_ARCHITECTURE_ID:......: x64
CMAKE_CXX_STANDARD:......................: 20
CMAKE_CXX_COMPILER_VERSION:..............: 19.37.32[82](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201385#step:9:83)6.1
CMAKE_CXX_SIZEOF_DATA_PTR:...............: 8
CMAKE_GENERATOR:.........................: Ninja
CMAKE_VERSION:...........................: 3.28.1
CMAKE_MINIMUM_REQUIRED_VERSION:..........: 3.20
VCPKG_TARGET_TRIPLET.....................:
CMAKE_DEBUG_POSTFIX......................:
GIT_COMMIT_HASH..........................: 5fea906d5a63a659524513b7304ddd627da6a5b0
CMake Paths
CMAKE_CURRENT_SOURCE_DIR.................: D:/a/godot-orchestrator/godot-orchestrator
CMAKE_TOOLCHAIN_FILE:....................:
CMAKE_SOURCE_DIR:........................: D:/a/godot-orchestrator/godot-orchestrator
CMAKE_COMMAND:...........................: C:/hostedtoolcache/windows/cmake/3.28.1/x64/cmake-3.28.1-windows-x[86](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201385#step:9:87)_64/bin/cmake.exe
CLANG_FORMAT_PROGRAM:....................:
SCONS_PROGRAM:...........................: C:/hostedtoolcache/windows/Python/3.12.1/x64/Scripts/scons.exe
CMAKE_CXX_COMPILER:......................: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.37.32822/bin/HostX64/x64/cl.exe
CMAKE_LINKER:............................: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.37.32822/bin/HostX64/x64/link.exe
CMAKE_BUILD_TOOL:........................: C:/ProgramData/chocolatey/bin/ninja.exe
vcpkg_executable:........................:
godot_debug_editor_executable:...........: D:/a/godot-orchestrator/godot-orchestrator/extern/godot-engine/bin/godot.windows.editor.dev.x86_64.exe
CMAKE_INSTALL_PREFIX:....................: C:/Program Files (x86)/orchestrator
CMAKE_BINARY_DIR:........................: D:/a/godot-orchestrator/godot-orchestrator/.out-windows-debug
GDEXTENSION_LIB_PATH:....................: D:/a/godot-orchestrator/godot-orchestrator/project/addons/orchestrator
Any ideas or suggestions on what could be the problem?
@Naros in my case the debug information format was making the compilation calls uncacheable.
In recent cmake version you can try setting CMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded
and see if it helps.
In slightly older version you would need:
string(REPLACE "/Zi" "/Z7" CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}")
string(REPLACE "/Zi" "/Z7" CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO}")
string(REPLACE "/Zi" "/Z7" CMAKE_CXX_FLAGS_RELWITHDEBINFO "${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")```
Hi @pwiecz I tried both solutions and neither seemed to work for debug builds.
@Naros I guess you'll have to try to determine why the compilations were uncacheable in your case by increasing verbosity and looking into ccache logs. For that you may have to build the project locally to have access to ccache logs.
Unfortunately, I cannot recall right now how exactly I was debugging my own case... :(
I am getting the message
Not saving cache because no objects are cached.
on windows workflows. I just made a small repo example to reproduce it: https://github.com/alemuntoni/ccache-hello-world)here the workflow file and here the workflow run.
You can see that I made also similar workflows for linux and macos, which work fine.
Am I doing something wrong?
--
As @hendrikmuhs pointed on my original question on #55, ccache isn't called on my workflow:
Could the issue be in my cmake call?
https://github.com/alemuntoni/ccache-hello-world/blob/e1f7a57576d028167218ae406ae0b04cbb881935/.github/workflows/Windows.yml#L23-L24