Closed pmqs closed 6 months ago
Note that the failing automated build checks with the new workflow file are to be expected.
Note that the failing automated build checks with the new workflow file are to be expected.
Are to be expected? What do you mean?
Note that the failing automated build checks with the new workflow file are to be expected.
Are to be expected? What do you mean?
It just means that this workflow triggers the warnings reported in #926. The compilation in the workflow deliberately uses -Werror
to promote warnings to errors so the workflow fails without the #926 fix
Given the different behaviour seen with #926 on Mac , I've just added building on Mac to the workflow matrix
Does this workflow work now?
Does this workflow work now?
Not quite. After your comment about the Microsoft compilers and their continued support for C89, I added more workflow to test the state of play with the C standards they support (c11 & c17). Nothing popped out.
Also, I'm trying out 32-bit builds on Linux & Microsoft -- issue #930 was found with that.
Should have this some time tomorrow to tidy it up..
Alrighty, thanks.
Latest update now building 100% with develop.
The workflow now tests as many C standards as possible with the following
gcc & clang standards are c89, gnu89, c94, c99, gnu99, c11, gnu11, c17, gnu17, c2x, gnu2x
cl standards are c11, c17 and clatest
This workflow will trigger a total of 173 compilations of zlib
. GitHub doesn't give out infinite CPU time for running workflows, so need to keep an eye on this. That said, I've been hitting this workflow quite hard over the last couple of days without a problem. I don't think there are enough PR's every month that mean we would blow the monthly CPU limit.
If it does become an issue, the workflow can always be disabled for PR's and only run manually.
One combination that isn't working, and has been explicitly excluded from the workflow, is Windows + clang + cmake -- created #932 to track that. It is trivial to enable if it gets fixed.
Missed out C20 with the Microsoft C compiler. Sorted now.
GitHub doesn't give out infinite CPU time for running workflows, so need to keep an eye on this.
Where do I find my CPU limit and how much time has been used against it?
GitHub doesn't give out infinite CPU time for running workflows, so need to keep an eye on this.
Where do I find my CPU limit and how much time has been used against it?
This link https://docs.github.com/en/get-started/learning-about-github/githubs-plans#github-free-for-personal-accounts says that you get 200 minutes/month.
If you look in the Action
tab & note that C Standard
says it uses 8 mins 2 seconds. I see some of the Fuzz tests taking a similar amount of time, so perhaps I was overreacting.
Actually 2000 minutes per month! Thank you for for looking into that.
Today's change does the following
What is -G Ninja
on the Windows cmake options?
What is
-G Ninja
on the Windows cmake options?
It gets cmake to use ninja instead of make to do the build. Supposed to be faster than make.
Used it here to match what was already done in cmake.yml
Applied. Thank you!
This workflow gets zlib built with all the C standards that gnu & clang support from c89 through to c2x (i.e. early c23).
It is setup to fail the workflow if there are any compiler warnings (by adding
-Werror
toCFLAGS
)This has highlighted a couple of compiler warnings. Will ticket them separately.