Moved the `FileSettings` out of the `Settings` and pass them around
explicitly. They can never be specified at the same time and are used
exclusively. The code hasn't been fully adjusted to reflect this as this
is only the refactoring without any functional changes.
Updates for the Qt 6.2.x and 6.5.x LTS versions are only being provided
to commercial customers so the latest version is the only feasible one
to use.
Builds with older 6.x versions are still being tested implicitly by
using the Qt versions provided by the various distros.
Removed all `macos-11` builds as `brew` no longer supports it and we use
it in most steps:
```
Warning: You are using macOS 11.
We (and Apple) do not provide support for this old version.
It is expected behaviour that some formulae will fail to build in this old version.
It is expected behaviour that Homebrew will be buggy and slow.
Do not create any issues about this on Homebrew's GitHub repositories.
Do not create any issues even if you think this message is unrelated.
Any opened issues will be immediately closed without response.
Do not ask for help from Homebrew or its maintainers on social media.
You may ask for help in Homebrew's discussions but are unlikely to receive a response.
Try to figure out the problem yourself and submit a fix as a pull request.
We will review it but may or may not accept it.
```
Also `brew` might no longer provide pre-built Qt5 packages which will
cause the step to run for hours as it will compile it on demand - see
https://github.com/danmar/cppcheck/actions/runs/6735637341/job/18314354679
for such an instance.
`ImportProject` is not needed outside of the command-line parsing so we
do not need it inside the `Settings` at all. We only use the
`fileSettings` in the executors.
Qt 5.15 will be EOL on May 26 so we should start switching away from it.
We already have issues with many of the previous versions and qmake on
legacy distros so we should cut that off.
I will add a Qt6 release build for Windows in another PR so it can be
tested. We should switch to it as the delivered build after the next
release and stop using Qt5 altogether in the CI in the release
afterwards (that would get rid of several build steps). We could leave
it so you could still try to build it but no longer support it so it is
up to the user to get it to work before removing it completely later on.
Oliver Stöneberg
Daniel Marjamäki
chrchr-github
Swasti Shrivastava
Paul Fultz II