add workflow to build with all available C standards

[pmqs]

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 to CFLAGS)

This has highlighted a couple of compiler warnings. Will ticket them separately.

[pmqs]

Note that the failing automated build checks with the new workflow file are to be expected.

[madler]

Note that the failing automated build checks with the new workflow file are to be expected.

Are to be expected? What do you mean?

[pmqs]

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

[madler]

Does this workflow work now?

[pmqs]

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..

[madler]

Alrighty, thanks.

[pmqs]

Latest update now building 100% with develop.

The workflow now tests as many C standards as possible with the following

• Linux gcc & clang with configure & cmake both 32-bit & 64-bit
• MacOS gcc & clang with configure & cmake on 64-bit
• Windows cl with cmake both 32-bit & 64-bit
• Windows gcc with cmake on 64-bit

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.

[pmqs]

Missed out C20 with the Microsoft C compiler. Sorted now.

[madler]

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?

[pmqs]

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.

[madler]

Actually 2000 minutes per month! Thank you for for looking into that.

[pmqs]

Today's change does the following

• Add clang + cmake on Windows now that #932 build cleanly.
• Add Wall/Wextra
• Disable C20 on MSVC for now -- not reliably available on the windows runner yet

[madler]

What is -G Ninja on the Windows cmake options?

[pmqs]

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

[madler]

Applied. Thank you!