Improved documentation of supported toolchains

[firewave]

We should specify and properly check the tooling we (cl)aim to support. Please feel free to post any additions/omissions as well as opinions and open talking points. At the end I would like to add this list to the readme.md or s separate file we link form there.

Here's a short overview:

Build systems (minimum):

• GNU Make
• CMake 2.8 3.5
• Qt qmake
• Microsoft Visual Studio 2013 2015

Compilers (minimum):

• GCC 4.6 4.8 5.1
• Clang 2.9 3.5
• Microsoft Visual Studio Compiler 18 (VS2013) 19.0 (VS2015)

Qt:

• 5.6
• 5.9.9
• 5.15.2
• 6.2+

Python:

• 2.7
• 3.4+ 3.6+

Distros/OSes (initial summary to determine tasks):

• Windows XP(?)
• Windows 7(?)
• Windows 10/11
  • any build system
  • any compiler
  • any(?) Qt version (https://download.qt.io/archive/qt/)
  • any Python version
• Ubuntu 12.04 (requires EOL repos to install packages)
  • CMake 2.8.7
  • GCC 4.6.3
  • Clang 3.0
  • no Qt5
  • Python 2.7.3/3.2.3
• Ubuntu 14.04
  • CMake 2.8.12
  • GCC 4.8.2
  • Clang 3.4
  • Qt 5.2.1
  • Python 2.7.6/3.4.3
• Ubuntu 16.04
  • CMake 3.5.1
  • GCC 5.4.0
  • Clang 3.8
  • Qt 5.5.1
  • Python 2.7.12/3.5.2
• Ubuntu 18.04
  • CMake 3.10.2
  • GCC 7.5.0
  • Clang ?
  • Qt ?
  • Python ?/?
• Ubuntu 20.04
  • CMake 3.16.3
  • GCC 9.3.0
  • Clang 10.0.0
  • Qt 5.12.8/no Qt6
  • Python ?/3.8.2
• Ubuntu 22.04
  • CMake 3.22.1
  • GCC 11.2.0
  • Clang 13.0.1
  • Qt 5.15.3/6.2.4
  • Python ?/3.10.4
• Ubuntu 24.04
  • CMake 3.28.3
  • GCC 13.2.0
  • Clang 18.1.3
  • Qt 5.15.13/6.4.2
  • Python ?/3.12.3
• Debian (version?)
• Fedora (version?)
• openSUSE (version?)
• ArchLinux (version?)
• FreeBSD (version?)
• Solaris (version?)
• Kali Linux
• CentOS 7
  • CMake 2.8.12
  • GCC 4.8.5
  • Clang 3.4.2
  • Qt 5.9.7
  • Python 2.7.5/3.6.8
• OS/2 (version?)
• Cygwin
• MinGW
• Raspberry Pi OS (version?)
• MacOS 10.15

Platforms:

• x86_64
• x86

Third-party libraries:

• PCRE (https://www.pcre.org/ - https://sourceforge.net/projects/pcre)
• TinyXML2 (https://github.com/leethomason/tinyxml2)
• PicoJSON (https://github.com/kazuho/picojson)

CI missing:

• GCC < 4.8
• Visual Studio 2013/2015/2017/2022
• Qt < 5.9
• Clang (explicit build) (no need for explicit build - implicitly done with clang-tidy which also provides compiler warnings)
• Ubuntu 12.04 (for GCC 4.6 via ppa) (no longer necessary since we raised the minimum GCC version to 4.8)
• Python 3.4 (no longer available)
• Visual Studio with msbuild (explicit build - implicitly done in release build - lost recently in regular CI)
• Windows Installer (only build on release tags)
• newer MacOS versions
• failure on compiler warnings (Clang/Visual Studio only currently)
• MinGW cross-compilation

Currently not working:

• MSYS2 on Windows
• Visual Studio 2015 build - broken by ae86536
• Ubuntu 14.04 GUI build - Improved documentation of supported toolchains #3596 (comment)
• Ubuntu 16.04 GUI build with CMake - Improved documentation of supported toolchains #3596 (comment)

Misc:

• missing build system feature parity

To be discussed:

• remove support for older Visual Studio versions
• remove support for EOL Python 3.x versions (depend on platform?)
• remove support for EOL Qt versions (depended on platform?)
• remove support for some build systems - currently none of them implement all build features we offer
  • remove Visual Studio project files from repository
  • remove qmake support
• remove "support" for Ubuntu 12.04 (and similar platforms) since it doesn't even have a proper CMake, Qt5 and Python 3.x version
  • raise the minimum GCC version (seems like we won't be able to run any system with it in the CI)
  • remove Python 2.x support since all platforms seem to have at least Python 3.4
• remove support for EOS Ubuntu versions

Tasks:

• raise minimum supported GCC version to 4.8 - bumped minimum supported GCC version to 4.8 #3768
• add Python 3.4 to CI - scriptcheck.yml: added Python 3.4 #3683
• integrate all Makefile targets/functionality into CMake - added make targets checkCWEEntries, validateXML and validateRules to CMake #4010 / added remaining make targets to CMake #4026
• integrate all qmake targets/functionality into CMake - refs #12066 - added CMake option BUILD_ONLINE_HELP to conditionally add online-help.qhc target to CMake #6818
• build with Qt version provided by platform on Linux - CI-unixish.yml: Use Qt version provided by the distro #3729
• build with Python version provided by platform on Linux - use Python version provided by platform in CI / prefer python3 #3776
• determine actual minimum supported Clang version - bumped minimum requirements to GCC 5.1 / Clang 3.5 / Visual Studio 2015 / CMake 3.5 #5398
• create Windows portable archive (release files without installer) - installer: added missing library configurations and removed unneeded Qt DLLs / refs #10771 - added initial portable package #4669
• remove defines used to control usage of C++11 features
  • remove OVERRIDE / FINAL - removed OVERRIDE and FINAL defines and use the keywords directly #3767
  • use feature test macros (https://en.cppreference.com/w/cpp/feature_test) for remaining ones
  • remove unnecessary __cplusplus checks - fail run-clang-tidy in case of compiler warnings / fixed Clang warnings / cleanups #4036 / 81efa0f
• prefer Python 3.x over Python 2.x - use Python version provided by platform in CI / prefer python3 #3776 / use python3 on debians too #3812 / fixed #12682 - deprecated support for Python 2.7 #6369
• restore msbuild Visual Studio build in CI - CI-windows.yml: added windows-2022, removed QT 5.9.9 and use msbuild instead of CMake for now #3730
• add Visual Studio 2022 to CI - CI-windows.yml: added windows-2022, removed QT 5.9.9 and use msbuild instead of CMake for now #3730
• align configuration of CMake and Visual Studio project files - aligned build options of Visual Studio project configurations and added them to CMake #4020
• add newer MacOs versions to CI - CI-unixish.yml: added macos-11 and macos-12 #4117
• fail build on compiler warnings - fail run-clang-tidy in case of compiler warnings / fixed Clang warnings / cleanups #4036 / refs #12021 - CI-windows.yml: fail build on compiler warnings / some cleanups #6982
• move remaining stuff from defunct Travis configuration to GitHub Actions - Moved some stuff from Travis to GitHub Actions / Cleanups #3715 / refs #8659 - fixed CMake installation / added tests for make and CMake install targets to CI #7100
• remove support for EOL Qt versions - fixed #12042 - deprecated building with Qt5 / build with Qt6 in CI / updated latest Qt in CI to 6.5.3 #4957 / fixed #13133 - removed deprecated Qt5 support #6678

[firewave]

I would prefer if we would define some target platforms and derive the minimum of a supported version from that - even if those might be already EOL or EOS. CentOS 7 and Ubuntu 12.04 (unfortunately not working in the CI) would be the lowest bar from my perspective.

We also need to do builds with the actual available Qt and Python version provided by the platform since we "cheat" in the CI by installing a specific version. This is not possible for actual users of those platforms so building might not actually work for them.

@danmar mentioned several times that there are some very specific platforms or configurations some users are building on so I would like to have some more details on that. This is not necessarily for CI (a single manual evaluation for a baseline might be enough) but just for documentation and decision purposes.

[firewave]

CC'ing @danmar @amai2012 @versat @orbitcowboy @pfultz2 @aggro80 @KenPatrickLehrmann @Ken-Patrick @rikardfalkeborn @chrchr-github @guillaume-uH57J9

[danmar]

Build systems (minimum):

Imho, we do not need to support very old tools. If somebody has a 10+ year old system he/she can still build the command line tool by running the compiler manually.

remove support for older Visual Studio versions

Imho it's ok to drop older VS support when we can't test it in CI anymore.

@danmar mentioned several times that there are some very specific platforms or configurations some users are building on so I would like to have some more details on that. This is not necessarily for CI (a single manual evaluation for a baseline might be enough) but just for documentation and decision purposes.

I don't remember details. But yes 10-20 year old distros are still used.

[firewave]

Imho it's ok to drop older VS support when we can't test it in CI anymore.

@danmar
I think it is feasible to support the two latest versions (that's the only we have in the CI anyways). For a usual open-source user the community editions are free so there's nothing preventing them from upgrading to a newer version. For enterprise customers it might be more problematic since you need to get licenses but I think using very outdated versions for production stuff has security implications which would prevent you from actually running such binaries. And even if we don't provide the Visual Studio project files for older versions you can still generate (the more ugly) ones for older versions via CMake.

I just gave it a spin with GCC 4.6 on Ubuntu 12.04 and it doesn't even compile. It bails out very early with lots of errors like these:

lib/library.h:474:28: sorry, unimplemented: non-static data member initializers
lib/library.h:474:28: error: in-class initialization of static data member 'name' of non-literal type
lib/library.h:475:23: sorry, unimplemented: non-static data member initializers
lib/library.h:475:23: error: ISO C++ forbids in-class initialization of non-const static member 'unique'

So I think we can toss that GCC 4.6 support into the bin and make GCC 4.8 the minimum since that works and we can actually test it in the CI.
Same for Python 2.7 support. If they use addons which don't work with Python 3 yet that should be possible to fix without much effort. Also Python 2.7 has been EOL for a while. I would add Python 3.4 to the CI though.

[danmar]

very outdated versions for production stuff has security implications which would prevent you from actually running such binaries

the users I have talked with can't upgrade so easily. especially upgrading a production system is not reasonable.

Distros/OSes (minimum):

I would like that it is clear that we do support all other distros/OSes also. If a user with a non-listed OS/distro has problems I would try my best to help them.

[firewave]

the users I have talked with can't upgrade so easily. especially upgrading a production system is not reasonable.

If such cases come up in the future it would be great if we could document it at least. If there is more common knowledge about such things it might help improve things and make it easier for the next user/support case.

I would like that it is clear that we do support all other distros/OSes also. If a user with a non-listed OS/distro has problems I would try my best to help them.

This is just something to track so we can determine a baseline for the individual tooling and know what we should be testing with. This would not be a list of "supported" platforms but "tested" ones IMO. Like the minimum supported version of GCC 4.6 but that probably hasn't worked in years and has not been tested at all. If we make any claims we should be able to actually fulfill them and back them up with testing.

[pfultz2]

I really dont see the need to support really old systems. Cppcheck is a dev tool which is meant to run in the dev environment not the the really old production systems that a user maybe targeting.

A dev environment is usually much more recent. The user is either ssh-ing/rsyncing into an old system or cross-compiling for the old system, all from a recent OS/distro. Even if they need to build with an older compiler(ie Visual Studio 2012) they can still install a newer compiler to build and run cppcheck. Furthermore, I fail to see how a recent OS/distro is inaccessible to a developer targeting an old system.

[danmar]

Cppcheck is a dev tool which is meant to run in the dev environment not the the really old production systems that a user maybe targeting.

yes. I agree.

Furthermore, I fail to see how a recent OS/distro is inaccessible to a developer targeting an old system.

I looked up a discussion I had in 2017 with an engineer:

• We have MinGW 3.3 and g++ 4.5.2.
  DM: I suggest that you install Cppcheck instead of compiling.
• Unfortunately our IT team has admin access to all computers and won't authorize the use of those installers. We're trying to compile as a work-around.

[danmar]

This would not be a list of "supported" platforms but "tested" ones IMO. Like the minimum supported version of GCC 4.6 but that probably hasn't worked in years and has not been tested at all. If we make any claims we should be able to actually fulfill them and back them up with testing.

ok sounds good to me. I am not against that we document what we test on.

If we can somehow add a CI pipeline that uses GCC 4.6 and it's not too much work to make that happy then I would like to stay with GCC 4.6. Otherwise.. yes I fear we have to change to 4.8. We can't claim we support 4.6 if it does not work at all.

[firewave]

If we can somehow add a CI pipeline that uses GCC 4.6 and it's not too much work to make that happy then I would like to stay with GCC 4.6. Otherwise.. yes I fear we have to change to 4.8. We can't claim we support 4.6 if it does not work at all.

I tried that with #3545 but that system lacks symbols which are necessary to be run within the CI. And I guess it will be some work to get GCC 4.6 to work again.

I really dont see the need to support really old systems. Cppcheck is a dev tool which is meant to run in the dev environment not the the really old production systems that a user maybe targeting.

If you integrate it within the CI it's not just a local system. But just like we are using older and newer systems for certain builds you should be able to do that within your CI nowadays. Unless you have some integration directly with the actual build like the CMake one.

• We have MinGW 3.3 and g++ 4.5.2.

That doesn't even supported C++11 at all I think - that probably hasn't been working in like longer than GCC 4.6 hasn't.

• Unfortunately our IT team has admin access to all computers and won't authorize the use of those installers. We're trying to compile as a work-around.

I always hated that there is only an installer. I prefer "portable" packages which allow me to just extract it somewhere and run it. I think we already do this packaging but just don't archive it with the releases. I think we should add that. We should add the change from the Debian package by Joachim which prefers the local configurations over the global path then.

[danmar]

That doesn't even supported C++11 at all I think - that probably hasn't been working in like longer than GCC 4.6 hasn't.

I compiled the democlient with gcc-4.4 until sourceforge finally upgraded it ~ 5-6 years ago. It was a pain though, I used a script to convert certain code constructs to be able to compile.

For information.. sourceforge shell uses gcc-4.8.5 now.

I prefer "portable" packages which allow me to just extract it somewhere and run it

yes maybe that is a way to get around the problem like that in some cases. as far as I know qt can't be executed on i.e. windows xp but probably it's possible to create a package with command line cppcheck.exe at least. I think it's ok that we can't offer the GUI.

[danmar]

I tried that with #3545 but that system lacks symbols which are necessary to be run within the CI. And I guess it will be some work to get GCC 4.6 to work again.

thanks for trying at least! well.. so I would also say it's ok to change to GCC 4.8. I don't volounteer to make GCC 4.6 work in a CI pipeline.

[pfultz2]

Unfortunately our IT team has admin access to all computers and won't authorize the use of those installers. We're trying to compile as a work-around.

If they are able to build/compile programs as a workaround, then why dont they build a newer gcc?

Furthermore, cppcheck is a 100% volunteer effort. If companies are making it so difficult for developers to have a productive dev environment then they should be investing either money, effort, or resources in order to support cppcheck on such arcane systems.

[danmar]

If they are able to build/compile programs as a workaround, then why dont they build a newer gcc?

I am not sure what effort that is but I would assume it's not just the compiler itself also some libraries.

Furthermore, cppcheck is a 100% volunteer effort. If companies are making it so difficult for developers to have a productive dev environment then they should be investing either money, effort, or resources in order to support cppcheck on such arcane systems.

Yes :-)

[danmar]

Furthermore, cppcheck is a 100% volunteer effort. If companies are making it so difficult for developers to have a productive dev environment then they should be investing either money, effort, or resources in order to support cppcheck on such arcane systems.

For information the engineer worked on NASA. I imagine it would be hard to convince NASA to fund Cppcheck, I guess we would need to get accepted at some high level as a prioritized tool.

[firewave]

Furthermore, cppcheck is a 100% volunteer effort. If companies are making it so difficult for developers to have a productive dev environment then they should be investing either money, effort, or resources in order to support cppcheck on such arcane systems.

Good point. Why should be more generous than than the Linux kernel? If something cannot be maintained and bitrots we have to drop broker stuff unless somebody steps up.

For information the engineer worked on NASA. I imagine it would be hard to convince NASA to fund Cppcheck, I guess we would need to get accepted at some high level as a prioritized tool.

NASA has shitloads of money and AFAIK they also open-source stuff and contribute to it. So if that is really

LLVM for instance is very aggressive in dropping supported toolchains and moving up the C++ standard requirement. There's probably more people relying on clang-tidy and custom plugins for it than Cppcheck.

If they are able to build/compile programs as a workaround, then why dont they build a newer gcc?

On Linux that will only work if you can target older runtimes libc and glibc runtimes (I have no idea how to do that). That's one of the problems why Ubuntu 12.04 doesn't work in the CI since those libraries are too old to run newer binaries.

thanks for trying at least! well.. so I would also say it's ok to change to GCC 4.8. I don't volounteer to make GCC 4.6 work in a CI pipeline.

Okay - so I place that in the decisions.

yes maybe that is a way to get around the problem like that in some cases. as far as I know qt can't be executed on i.e. windows xp but probably it's possible to create a package with command line cppcheck.exe at least. I think it's ok that we can't offer the GUI.

I am on board with Windows 7 support. But Windows XP support is madness. Lots of runtimes and libraries no longer work on that. And if you need it you need to you have to use an EOL Qt version (everything but Qt 6.2 is essentially EOL now since they changed their business model). The oldest Qt version we were using in the CI was 5.6 via Appveyor. So it's not clear if we might even build on ubuntu 14.04 with Qt 5.2. I would broaden that as a start and try to define it more clearly.

[guillaume-uH57J9]

Don't have too much pity on large orgs or corporation running legacy systems with unmaintained software, unless they're willing to fund work on supporting such old systems.

And anyone wishing to run cppcheck of dusty old systems could make a static build of cppcheck using a recent compiler, then just copy the binary to that old dusty system.
I don't know if cppcheck's build system already have a static build option, worse case they could contribute and add that option. In any case, a static build is a more reasonable ask than GCC 4.6 support.

Bumping requirements to GCC 4.8 would help unlock C++11 usage. GCC 4.8's changelog describe their C++11 support as still being experimental, but it's the first major GCC release with virtually complete C++11 support. https://gcc.gnu.org/gcc-4.8/changes.html

[firewave]

And anyone wishing to run cppcheck of dusty old systems could make a static build of cppcheck using a recent compiler, then just copy the binary to that old dusty system.

Didn't think of that. That's the obvious solution.

I don't know if cppcheck's build system already have a static build option, worse case they could contribute and add that option. In any case, a static build is a more reasonable ask than GCC 4.6 support.

This and the previous point are something to consider if the next case comes up. Maybe it's something those people didn't think about or are not even aware of. Just because those people are being tasked with doing something on *nix doesn't mean they actually have any clue about it (I am speaking from experience).

Bumping requirements to GCC 4.8 would help unlock C++11 usage. GCC 4.8's changelog describe their C++11 support as still being experimental, but it's the first major GCC release with virtually complete C++11 support. https://gcc.gnu.org/gcc-4.8/changes.html

Big emphasis on the "experimental" and "virtually".

[guillaume-uH57J9]

Big emphasis on the "experimental" and "virtually".

GCC 4.8 C++11 is pretty much complete. I said virtually complete because it lacks "Minimal support for garbage collection and reachability-based leak detection" (N2670) https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
N2670 is an optional part of C++, compilers can claim C++11 support without implementing GC. But if people really want to implement GC, there's a provision for that in the standard.

At work I'm working on a reasonably large C++ codebase that we've been building continuously (we have CI) for a few years with GCC 4.8 + C++11 flag. We're not using every C++11 features but a number of common ones (TLS, lambda, regex, shared_lock, memory-safe function in libc, ..) without any compiler issue so far.

[firewave]

At work I'm working on a reasonably large C++ codebase that we've been building continuously (we have CI) for a few years with GCC 4.8 + C++11 flag. We're not using every C++11 features but a number of common ones (TLS, lambda, regex, shared_lock, memory-safe function in libc, ..) without any compiler issue so far.

Used it for years at my previous workplace as well. Main issue was with the initializer list stuff which it gets confused by often so you have to stick with simple braces in those cases.

[firewave]

Compilation with Qt 5.2 on Ubuntu 14.04 fails:

In file included from /usr/include/qt5/QtCore/qobjectdefs.h:47:0,
                 from /usr/include/qt5/QtGui/qwindowdefs.h:46,
                 from /usr/include/qt5/QtWidgets/qwidget.h:45,
                 from /usr/include/qt5/QtWidgets/qmainwindow.h:45,
                 from /usr/include/qt5/QtWidgets/QMainWindow:1,
                 from /cppcheck/gui/mainwindow.h:22,
                 from /cppcheck/gui/mainwindow.cpp:19:
/usr/include/qt5/QtCore/qobjectdefs_impl.h: In instantiation of 'struct QtPrivate::AreArgumentsCompatible<ErrorItem, ErrorItem>':
/usr/include/qt5/QtCore/qobjectdefs_impl.h:599:21:   required from 'struct QtPrivate::CheckCompatibleArguments<QtPrivate::List<const ErrorItem&>, QtPrivate::List<const ErrorItem&> >'
/usr/include/qt5/QtCore/qobject.h:241:80:   required from 'static QMetaObject::Connection QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const typename QtPrivate::FunctionPointer<Func2>::Object*, Func2, Qt::ConnectionType) [with Func1 = void (ThreadHandler::*)(const ErrorItem&); Func2 = void (ResultsView::*)(const ErrorItem&); typename QtPrivate::FunctionPointer<Func>::Object = ThreadHandler; typename QtPrivate::FunctionPointer<Func2>::Object = ResultsView]'
/cppcheck/gui/mainwindow.cpp:135:88:   required from here
/usr/include/qt5/QtCore/qobjectdefs_impl.h:573:42: error: invalid use of incomplete type 'class ErrorItem'
         enum { value = sizeof(test(dummy())) == sizeof(int) };
                                          ^
In file included from /cppcheck/gui/resultsview.h:24:0,
                 from /cppcheck/cmake.output/gui/ui_mainwindow.h:23,
                 from /cppcheck/gui/mainwindow.h:28,
                 from /cppcheck/gui/mainwindow.cpp:19:
/cppcheck/gui/report.h:26:7: error: forward declaration of 'class ErrorItem'
 class ErrorItem;
       ^
In file included from /usr/include/qt5/QtGui/qwindowdefs.h:45:0,
                 from /usr/include/qt5/QtWidgets/qwidget.h:45,
                 from /usr/include/qt5/QtWidgets/qmainwindow.h:45,
                 from /usr/include/qt5/QtWidgets/QMainWindow:1,
                 from /cppcheck/gui/mainwindow.h:22,
                 from /cppcheck/gui/mainwindow.cpp:19:
/usr/include/qt5/QtCore/qobject.h: In instantiation of 'static QMetaObject::Connection QObject::connect(const typename QtPrivate::FunctionPointer<Func>::Object*, Func1, const typename QtPrivate::FunctionPointer<Func2>::Object*, Func2, Qt::ConnectionType) [with Func1 = void (ThreadHandler::*)(const ErrorItem&); Func2 = void (ResultsView::*)(const ErrorItem&); typename QtPrivate::FunctionPointer<Func>::Object = ThreadHandler; typename QtPrivate::FunctionPointer<Func2>::Object = ResultsView]':
/cppcheck/gui/mainwindow.cpp:135:88:   required from here
/usr/include/qt5/QtCore/qglobal.h:669:47: error: static assertion failed: Signal and slot arguments are not compatible.
 #define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), Message)
                                               ^
/usr/include/qt5/QtCore/qobject.h:228:9: note: in expansion of macro 'Q_STATIC_ASSERT_X'
         Q_STATIC_ASSERT_X((QtPrivate::CheckCompatibleArguments<typename SignalType::Arguments, typename SlotType::Arguments>::value),
         ^

[firewave]

On Ubuntu 16.04 is is not possible to build the GUI with CMake since Qt5LinguistToolsConfig.cmake is somehow missing from qttools5-dev. It does work with qmake though.

The qmake has hard-coded Z3 support. That needs to be made optional as well.

I really think we should give qmake the boot if we have feature parity with it in CMake (the Qt tests are still missing). It's basically a mix of what we offer in make and CMake but lacks lots of both of them - except for the Qt-based tests. It also requires some additional files which need to be maintained which they aren't currently since not all of the Qt tests are being run in the CI (some seem to requite a X server) and thus some don't even compile/work.

[danmar]

On Ubuntu 16.04 is is not possible to build the GUI with CMake

I don't have any issues dropping support for GUI in Ubuntu 16.04.

I really think we should give qmake the boot if we have feature parity with it in CMake (the Qt tests are still missing).

If we achieve feature parity.. then sure why not.

[firewave]

Interestingly there is a compiler version check in cli/main.cpp. That should probably be performed in an early common include instead or removed completely since the build will probably never reached that file if the compiler is not supported.

[firewave]

The only thing which is exclusive to the Appveyor build is the usage of Visual Studio 2013 and Qt 5.6. The Visual Studio 2015 build was broken by ourselves and hasn't be enabled in quite a while.

The Qt version can be simply added to the GitHub actions but is not really necessary since you can get any version for Windows easily - and since it is not part of the platform you actually have to get it, so fetching a different version is actually not a big issue. But that is not really necessary since a GUI build with the platform version on Ubuntu 16.04 would test such a Qt version since it comes with Qt 5.5. I forgot the GUI build doesn't work on Ubuntu 16.04 - but since it is fine the GUI will not build on it it might still not be necessary. But the cut-off version of Qt is still not decided.

So I suggest we drop at least the Visual Studio 2013 support which would allow us to completely drop the Appveyor builds. There are some holes in the GitHub actions but that will be incrementally addressed in the future.

[danmar]

So I suggest we drop at least the Visual Studio 2013 support which would allow us to completely drop the Appveyor builds. There are some holes in the GitHub actions but that will be incrementally addressed in the future.

this is OK for me.

[firewave]

The OVERRIDE define can be replaced with just the override usage now we move to GCC 4.8. We have been doing this in the GUI code already.

[danmar]

The OVERRIDE define can be replaced with just the override usage now we move to GCC 4.8. We have been doing this in the GUI code already.

this is ok for me. will be a relief.