This adds support for using the `CLICOLOR_FORCE` environment variable to
force color output in Linux even when a tty is not used, mimicking
behavior in [CMake and other
tools](https://bixense.com/clicolors/#bug-reports). The primary intent
is to allow color to be output when cppcheck is run in CI, for example.
I chose to not add it in the help output. But I don't have a strong
opinion it can be added there also.
This option was added for the safety certification. It could be very bad
if a user runs one version of cppcheck and thinks that he runs another
version.
I accidentally specified `MATCHCOMPILER=1` and only later realized that
the matchcompiler was not being used as it requires `yes` instead. So
bail out on this.
This reverts commit fd9af82a86bc184dc659cd193bd1f8a148cb51fc.
We have a very outdated daca client which is wrecking havoc because it
still relies on this.
The current versions only have partial C++11 support which fortunately
has caused us only few issues so far but it would be good to finally
have fully working C++11 support. This also gets rid of several CI
builds on very outdated platforms.
The outdated platforms were used to also test CMake 2.8 but as future
versions of CMake will drop combability with CMake < 3.5 this is a good
time to also drop that requirement on our part.
This PR does not remove or update any outdated code.
Although these files are part of our repo changes are being done via
their original projects so it might make sense to treat these as system
includes for some people instead of local ones.
Co-authored-by: Daniel Marjamäki <daniel.marjamaki@gmail.com>
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.
Currently the `AddonInfo` is generated and discarded on each addon
invocation. This leads to an unnecessary process invocation for each
addon on each file.
Also if an addon is completely broken we will still perform the whole
analysis only for it to be failed at the end so we should bail out early
if we know it doesn't work at all.
