New Github Actions (fix #199)

[pinam45]

New GitHub Actions, like last time in #132 it is heavily inspired by my dynamic_bitset Github Actions.

Fix #199

Local actions

The new workflows are better organized using "local" actions:

• Setup ccache in .github/actions/setup_ccache
• Setup CMake in .github/actions/setup_cmake/action.yml
• Install SFML in .github/actions/install_sfml/action.yml

New workflows

The workflow are now separated depending on the build environment:

• Ubuntu: build on ubuntu-20.04 using gcc-9 / gcc-10 / clang-10 / clang-11 / clang-12 in Debug / Release
  (ubuntu-18.04 disabled because SFML seems to have dependencies problems with it)
• Windows MinGW: build on windows-2019 / windows-2022 using the available gcc / clang in Debug / Release
  (currently mingw-w64-x86_64-gcc-11.2.0-10 and mingw-w64-x86_64-clang-13.0.1-3)
• Windows Visual Studio: build on windows-2019 / windows-2022 using Visual Studio 16 / Visual Studio 17 in Debug / Release targeting Win32 / x64
  (using the default toolsets as SFML doesn't compile using ClangCL on the 2.5.1 tag but the issue is fixed on branch 2.6.x)
• MacOS: build on macos-10.15 / macos-11 using Xcode 10.3 / Xcode 11.7 / Xcode 12.4 / Xcode 12.5.1 / Xcode 13.2.1 in Debug / Release
  (I only kept the majors versions of Xcode otherwise the workflow the veeeeeery long)

I also created a workflow dedicated to clang-format:

• clang-format-lint-action using https://github.com/DoozyX/clang-format-lint-action
  (as it was already used before)

Badges

I added the badges to the README, at the moment it might look like this:

But when the workflow will be run on master it will look like this:

C++11

The old Github Action where invoking CMake with -D CMAKE_CXX_STANDARD=11 as some old compilers still use C++98 as default standard and the project was requiring C++03.
But according to #7 C++11 is now the minimum required standard so I made it a requirement on the ImGui-SFML target in the CMakeLists.txt

Note

The Windows MinGW workflow might need to be re-run the first time to let the gcc jobs bootstrap the SFML installation cache as the CMake configuration of SFML fails when using MinGW with clang stating that it doesn't find OpenAL, quite strange but we are here to build imgui-sfml, not SFML, so until it is fixed I think using the gcc built version from the cache is good enough.

To re-run the jobs:

[pinam45]

Well, as expected the Windows MinGW workflow needs a re-run.

[eliasdaler]

Thanks a lot for this PR!

I have some concerns about the number of builds that you have here... I think that x86/Win32 build should be dropped - this will already cut a lot computation. It's very rarely used these days...
I also think that "windows-2022 - VS2022" etc. should be named "Windows - VS2022" and so on, because seeing "Windows 2022" is confusing

As for Ubuntu... I'd leave gcc-9 and clang-10 only - I really doubt that there will be any differences there because we're not using a lot of fancy C++14/17 etc. code.

As for MacOS... I'm not really sure how quickly XCode evolves? I think we should use 13.2, because that's the version that SFML's CI uses and MacOS seems to be moving forward quickly, so SFML's MacOS implementation is not guaranteed to work on older versions.

[eliasdaler]

Thanks a lot! Merged

[pinam45]

Great, thanks to you for all the work on this project.

[eliasdaler]

For some reason if fails in master now. Any ideas why it’s happening?
(Fails to find OpenAL in MinGW build)

[pinam45]

Sorry I missed the notification, this is the issue I mentioned in the "Note" of the first message, you need to re-run the workflow.

[eliasdaler]

Still failing for Clang on MinGW

[eliasdaler]

Is it possible to group all these runs into one "run", btw?

[oprypin]

Yes, just put them all into one file -- which is how I'd do it anyway in the first place. These really aren't different workflows, it's the same workflow on several systems.