Require C++14, massive CMake cleanup

[tamiko]

Closes #10296

This pull request ended up quite a bit more massive than I anticipated. Let me explain:

I think the configuration logic that I introduced with DEAL_II_WITH_CXX11, DEAL_II_WITH_CXX14, and DEAL_II_WITH_CXX17 mutated into an unmaintainable mess. The main issue is the fact that support for a language standard is controlled by the compiler flag -std=c++XY. Consequently the CMake configuration had to honor this while at the same time allowing to set the standard via DEAL_II_WITH_CXXxy. Now the problem is there are two ways of specifying the same thing and one has to start to get really smart about guessing what actually should be happen... (for the curious: We ended up implementing some very weird quinary logic thing...) To make it short I simply removed the whole damn thing. The behavior is now as follows:

• We do not set any C++ language flag at all and thus default to whatever the compiler sets as default. This is C++14 for all compiler versions you actually want to use (Clang-6 onwards, GCC-6 onwards, https://gist.github.com/ax3l/53db9fa8a4f4c21ecc5c4100c0d93c94).
• We now simply check whether we have C++14 support with the given configuration. If we fail detecting C++14 support we simply emit fatal error and print an error message.
• If we detect C++17 support (for the given configuration) we export the preprocessor macro DEAL_II_HAVE_CXX17 that can be used deal.II internally for our wrapper include files, etc.

I think this is a much saner approach than the mess we had.

I will add one automagic configuration feature back, though: If we detect a very old compiler we will simply set -std=c++14 as a compiler flag unconditionally. This is safe insofar that they actually only support C++14 at maximum...

[kronbichler]

This looks very good to me and has my support. I like the idea of pushing the selection of the standard to the user. Yet, it might be surprising for some users that we are now not aggressively looking for the newest standard available, so I think it might be worth documenting it on the cmake documentation web page as remarked below.

[masterleinad]

Hmm...I can configure with both MSVC 2017 and 2019.

[tamiko]

@masterleinad The last version seems to work - I simply setting -Werror to were we need it.

[masterleinad]

Still works for me.

[tjhei]

Let me know if I can test anything.

[drwells]

What a very interesting MSVC failure:

D:\a\dealii\dealii\include\deal.II/physics/elasticity/standard_tensors.h(72): error C2864: 'dealii::Physics::Elasticity::StandardTensors<1>::I': a static data member with an in-class initializer must have non-volatile const integral type or be specified as 'inline' [D:\a\dealii\dealii\build\source\physics\elasticity\obj_physics_elasticity_debug.vcxproj]
  D:\a\dealii\dealii\include\deal.II/physics/elasticity/standard_tensors.h(76): note: type is 'const dealii::SymmetricTensor<2,1,double>'
  D:\a\dealii\dealii\include\deal.II/physics/elasticity/kinematics.h(285): note: see reference to class template instantiation 'dealii::Physics::Elasticity::StandardTensors<1>' being compiled
  D:\a\dealii\dealii\build\source\physics\elasticity\kinematics.inst(18): note: see reference to function template instantiation 'dealii::Tensor<2,1,double> dealii::Physics::Elasticity::Kinematics::F<1,double>(const dealii::Tensor<2,1,double> &)' being compiled
D:\a\dealii\dealii\include\deal.II/physics/elasticity/standard_tensors.h(105): error C2864: 'dealii::Physics::Elasticity::StandardTensors<1>::S': a static data member with an in-class initializer must have non-volatile const integral type or be specified as 'inline' [D:\a\dealii\dealii\build\source\physics\elasticity\obj_physics_elasticity_debug.vcxproj]
  D:\a\dealii\dealii\include\deal.II/physics/elasticity/standard_tensors.h(109): note: type is 'const dealii::SymmetricTensor<4,1,double>'
D:\a\dealii\dealii\include\deal.II/physics/elasticity/standard_tensors.h(121): error C2864: 

[drwells]

There must be something off with how we now handle DEAL_II_HAVE_CXX14_CONSTEXPR.

[drwells]

FWIW the current state of this is fine on GCC 5.4.0.

[tamiko]

@drwells Excellent. It also looks quite promising on all other configurations:

Host	Configuration	Commit	Build errors	Build warnings	Failing tests	Passing tests
tester	Clang-10.0.0-c++14-cleanup-autodetection	a54a11	0	300	0	0
tester	Clang-9.0.1-c++14-cleanup-autodetection	a54a11	0	0	0	0
tester	Clang-8.0.1-c++14-cleanup-autodetection	a54a11	0	0	0	0
tester	Clang-7.1.0-c++14-cleanup-autodetection	a54a11	0	0	0	0
tester	Clang-6.0.1-c++14-cleanup-autodetection	a54a11	0	0	0	0
tester	Clang-10.0.0-c++14-cleanup-autodetection	95cbd3	0	300	0	0
tester	Clang-9.0.1-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	Clang-8.0.1-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	Clang-7.1.0-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	Clang-6.0.1-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	Clang-5.0.2-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	Clang-4.0.1-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	GNU-10.1.0-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	GNU-9.3.0-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	GNU-9.3.0-c++14-cleanup-avx2-O3	95cbd3	0	0	0	0
tester	GNU-8.4.0-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	GNU-7.4.0-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	GNU-6.5.0-c++14-cleanup-autodetection	95cbd3	0	0	0	0
tester	GNU-4.9.4-c++14-cleanup-autodetection	95cbd3	null	null	null	null
tester	GNU-9.3.0-c++14-cleanup-ubuntu-lts-20	95cbd3	0	0	0	0
tester	GNU-7.5.0-c++14-cleanup-ubuntu-lts-18	95cbd3	0	0	0	0

[tamiko]

This now compiles on Windows.

[tamiko]

@drwells This is now rebased (no change except tracing changes to config.h.in that I made in another PR).

[drwells]

👍

[tamiko]

:-)

[tamiko]

4 approvals, ready to merge tag and all tests passed :-) I think I will be bold and merge my own pull request.

[masterleinad]

Let's see if hell breaks loose now. 😉