search

roystgnr / MetaPhysicL

Metaprogramming and operator-overloaded classes for numerical simulations
Other
22 stars 12 forks source link

C++17 compatibility #68

Closed roystgnr closed 3 years ago

roystgnr commented 3 years ago

This replaces all our deprecated-in-C++11 removed-in-C++17 API calls with non-obsolete C++11 API calls.

Hopefully this will fix some of the CI failures uncovered in https://github.com/libMesh/libmesh/pull/2842

We need some more work if we want to restore a C++98-backwards-compatibility mode to our test suite, but that's been true for a while; nobody's been testing MetaPhysicL against anything less than C++11 and C++98 compatibility for even the headers that were intended to retain it has been broken.

@lindsayad, do you happen to have a MOOSE build on Mac handy to test this against? I can't easily replicate the C++17 issues on Linux (where I have libstdc++ and not the more stringent libc++, even when using clang++), and I haven't been building anything bigger than this on my new Macbook yet.

lindsayad commented 3 years ago

I don't have one handy (I use a Linux desktop), but I can build MOOSE on my Mac for sure.

On Thu, Jan 28, 2021 at 3:08 PM roystgnr notifications@github.com wrote:

This replaces all our deprecated-in-C++11 removed-in-C++17 API calls with non-obsolete C++11 API calls.

Hopefully this will fix some of the CI failures uncovered in libMesh/libmesh#2842 https://github.com/libMesh/libmesh/pull/2842

We need some more work if we want to restore a C++98-backwards-compatibility mode to our test suite, but that's been true for a while; nobody's been testing MetaPhysicL against anything less than C++11 and C++98 compatibility for even the headers that were intended to retain it has been broken.

@lindsayad https://github.com/lindsayad, do you happen to have a MOOSE build on Mac handy to test this against? I can't easily replicate the C++17 issues on Linux (where I have libstdc++ and not the more stringent libc++, even when using clang++), and I haven't been building anything bigger than this on my new Macbook yet.

You can view, comment on, or merge this pull request online at:

https://github.com/roystgnr/MetaPhysicL/pull/68 Commit Summary

  • Use ax_cxx_compile_stdcxx from ACSM
  • Always check C++11 conformance
  • Eliminate code that was deprecated in C++17
  • Guard newly-C++11-only headers

File Changes

Patch Links:

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/roystgnr/MetaPhysicL/pull/68, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOGA4CWKNGJIF5MINZYYN3S4HVALANCNFSM4WX4VWPA .

lindsayad commented 3 years ago

I'm checking this out. Currently getting some errors related to @jwpeterson's custom C++11 feature checks after the testing from ax_cxx_compile_stdcxx.m4, so going to try to pin down what those issues are. Always a good day when digging into m4 😆

lindsayad commented 3 years ago

Here is the relevant part from config.log. I added some echos for the values of the flags being used to compile the test program and $switch seems to be the problem here.

configure:15578: Found C++14 standard support
configure:16599: checking whether mpicxx supports C++11 features by default
configure:16895: mpicxx -c -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong  -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isystem /Users/lindad/miniconda3/envs/moose-petsc/include -D_FORTIFY_SOURCE=2 -isystem /Users/lindad/miniconda3/envs/moose-petsc/include conftest.cpp >&5
configure:16895: $? = 0
configure:16903: result: yes
configure:17586: Found C++11 standard support
configure:17602: Using support for C++14 standard
configure:17805: result: <<< Disabling GLIBCXX debugging on Darwin >>>
configure:18248: result: <<< Configuring libMesh with methods "oprof dbg" >>>
configure:18414: result: <<< Compiler warnings are just warnings >>>
configure:18484: result: <<< Disabling extra paranoid compiler warnings >>>
configure:18522: checking for C++11 auto keyword support
configure:18532: CXXFLAGS is -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong  -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isystem /Users/lindad/miniconda3/envs/moose-petsc/include
configure:18534: switch is -h std=c++1z
configure:18536: libmesh_CXXFLAGS is  
configure:18555: mpicxx -c -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong  -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isystem /Users/lindad/miniconda3/envs/moose-petsc/include -h std=c++1z   -D_FORTIFY_SOURCE=2 -isystem /Users/lindad/miniconda3/envs/moose-petsc/include conftest.cpp >&5
clang-11: error: unknown argument: '-h'
clang-11: error: no such file or directory: 'std=c++1z'; did you mean '-std=c++1z'?
configure:18555: $? = 1
lindsayad commented 3 years ago

This is bad code in ax_cxx_compile_stdcxx.m4. If all the switches fail for a given language support level, switch should be made empty. Instead right now all the switches fail for C++17 and the last value of switch (-h std=c++1z) is retained even though C++14 support is available by default. Consequently in later checks we apply this non-empty switch value which destroys the configuration process

lindsayad commented 3 years ago

Good old BuildTools 😆 

commit 082ed11b7b61d718e2f585d0afade5ef6de04901 (HEAD, origin/master, origin/HEAD)
Author: BuildTools <roystgnr@ices.utexas.edu>
Date:   Wed Jan 27 13:24:02 2021 -0600
lindsayad commented 3 years ago

Ok I was able to fix my issue with https://github.com/libMesh/autoconf-submodule/pull/5

jwpeterson commented 3 years ago

Currently getting some errors related to @jwpeterson's custom C++11 feature checks

This could never have been caused by my beautiful m4 code.

lindsayad commented 3 years ago

Ok with clang 11 on my Mac, I'm able to build and install libmesh with c++17 enabled. I'm going to build and test MOOSE but I expect that will go smoothly

lindsayad commented 3 years ago

Well building MOOSE did not go smoothly per https://github.com/libMesh/libmesh/pull/2842#issuecomment-770064934

roystgnr commented 3 years ago

To clarify: building MOOSE did finally go smoothly after libMesh Eigen was fully upgraded too? So this PR ought to be good to merge?

lindsayad commented 3 years ago

Correct

On Jan 30, 2021, at 6:36 PM, roystgnr notifications@github.com wrote:

 To clarify: building MOOSE did finally go smoothly after libMesh Eigen was fully upgraded too? So this PR ought to be good to merge?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

roystgnr commented 3 years ago

Just holding off until we resolve https://github.com/libMesh/autoconf-submodule/pull/5 - once we're happy there I'll want to pull that update to the submodule here too.

roystgnr commented 3 years ago

Since we're probably going to get by without further ACSM updates it's likely that this won't need any updates after merge.