bumped minimum requirements to GCC 5.1 / Clang 3.5 / Visual Studio 2015 / CMake 3.5

[firewave]

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.

[firewave]

This will also allow us to properly use const_iterator in all cases since we no longer have to support the broken STL debug containers.

These versions also represent the minimum required version to be able to use C++14 (based on llvm/llvm-project@20644a9).

GCC 5.1 has been released on April 22, 2015 and Clang 3.5 is from 2014. I have not yet checked which version of Visual Studio has proper C++14 support - LLVM specified Visual Studio 2017 but they also had that for C++11 support.

A side effect of this is that we no longer have systems in the CI which check the CMake 2.8 compatibility. But as features of that will no longer be supported in shortly upcoming version we can no longer rely on that and we already partially require CMake 3.9. I will check which version should be the new minimum.

[firewave]

Current CMake already warns:

CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
Compatibility with CMake < 3.5 will be removed from a future version of
CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.

[firewave]

FYI CMake 3.28 removed support for Visual Studio 2012 and deprecated support for Visual Studio 2013. So no need to act on that.

[firewave]

Here's a feature matrix which displays that GCC 5.x is required for "full" C++11 support: https://en.cppreference.com/w/cpp/11.

But according to that you also need Clang 3.8 and Visual Studio 2015. I would still go by the LLVM reference (which was deemed sufficient for introducing C++14 feature) as a first step.

[firewave]

Looking at https://en.cppreference.com/w/cpp/14 - GCC 5 (except for a partial feature), Clang 3.4 and Visual Studio 2015 provide full C++14 support.

[firewave]

With Visual Studio 2012 out of support and Visual Studio 2013 support running out in April 2024 (see https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing#older-versions-of-visual-studio) I think we should bump it to Visual Studio 2015.

As we are only actively testing with Visual Studio 2019 and up there's no guarantee it will be working anyways. (Also I could get rid of those old installations on my local system).

[gruenich]

Time to merge this, isn't?

[firewave]

Time to merge this, isn't?

Probably. At I intended to, but I as I am currently not in the state to do proper work or follow-up on things I have not been on top for things for the past week and it will possibly be like that for a bit longer.

[firewave]

This is ready for review now. I think I will be able to guide this enough.

I also have direct follow-up PRs which clean up the CMake part a bit.

[danmar]

hmm.. what is the problem you try to solve.. on the sourceforge server, gcc 4.8 is installed and I cannot upgrade it easily. It is used to build the democlient: https://cppcheck.sourceforge.io/demo/

$ g++ --version
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)

we use the Makefile to build the democlient so the changes in the cmake does not matter much.. but if we don't compile with gcc 4.8 in the github actions anymore there will soon be code that is not handled..

[firewave]

but if we don't compile with gcc 4.8 in the github actions anymore there will soon be code that is not handled..

We had very few breakage in that way.

You could also build a static binary on a newer system to deploy to that system. Or you could build it using Clang - maybe that version matches the new requirement.

[danmar]

We had very few breakage in that way.

I remember before they upgraded gcc to 4.8 it was horrible. I had sed scripts that changed certain code constructs before compiling.. I rather not go back to such solution..

You could also build a static binary on a newer system to deploy to that system. Or you could build it using Clang - maybe that version matches the new requirement.

clang is not available on the server.. but yeah it might be possible to compile a static binary.. but I assume I can't compile it on latest linux distros and expect that it works on their server..

[danmar]

We had very few breakage in that way.

are you saying that we haven't compiled with gcc 4.8 ?

if we did manage to compile with 4.8 until now can we keep the build or what is the problem with that?

[firewave]

but yeah it might be possible to compile a static binary.. but I assume I can't compile it on latest linux distros and expect that it works on their server..

That is the point of a static binary that it should work on any system as it is fully contained.

We had very few breakage in that way.

are you saying that we haven't compiled with gcc 4.8 ?

I meant that we seldom had build failures which were caused by GCC 4.8.

[danmar]

That is the point of a static binary that it should work on any system as it is fully contained.

I am not 100% sure. The linux kernel is not embedded into the binary. What if a system call interface or something is changed..

I meant that we seldom had build failures which were caused by GCC 4.8.

I would feel afraid that we will not discover this during development. And then I discover it after the release and it's much more complex to solve it then.

[danmar]

I am not 100% sure. The linux kernel is not embedded into the binary. What if a system call interface or something is changed..

I have tried to build a static cppcheck binary and uploaded it to the server.. and as far as I see it works fine to execute it in the server shell..

so as far as I see this is an option for me. I don't think we need to stick to gcc-4.8 for the democlient at least.

[danmar]

I approve this.

[firewave]

The linux kernel is not embedded into the binary. What if a system call interface or something is changed..

I do not think that it is very likely. We also don't do that much stuff which should dependent on evolving syscalls. If you don't always use the the bleeding-edge glibc that can be circumvented I guess.

I have tried to build a static cppcheck binary and uploaded it to the server.. and as far as I see it works fine to execute it in the server shell..

so as far as I see this is an option for me. I don't think we need to stick to gcc-4.8 for the democlient at least.

Great!