Skip to content
This repository was archived by the owner on Jul 8, 2022. It is now read-only.

Conversation

@t-b
Copy link
Collaborator

@t-b t-b commented Jan 11, 2020

Closes #626.

@t-b t-b requested review from bourtemb and mliszcz as code owners January 11, 2020 02:02
@mliszcz
Copy link
Collaborator

mliszcz commented Jan 11, 2020

+1 for this PR, but I'm not sure what is the purpose of checking for relaxed constexpr support if we still need to be compatible with C++11. We are just doubling implementation effort this way (If we need certain computation to happen at compile time we still need to provide #else clause with template-based solution for C++11-only compilers).

@t-b
Copy link
Collaborator Author

t-b commented Jan 14, 2020

@mliszcz My idea is that we only use relaxed constexpr and not the C++11 one. The plan is to move to C++14 in august, so I don't think we need to have constexpr for C++11 and C++14.

@t-b t-b mentioned this pull request Jan 17, 2020
Copy link
Member

@bourtemb bourtemb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for this PR too!
Thanks @t-b for the initiative.
Please check my minor review comments.

@t-b
Copy link
Collaborator Author

t-b commented Jan 20, 2020

Indentation is fixed.

@t-b t-b force-pushed the require-c++11-and-cmake-3.7 branch 2 times, most recently from b9479d8 to 1f8c2c8 Compare January 21, 2020 16:57
@t-b
Copy link
Collaborator Author

t-b commented Jan 22, 2020

@mliszcz @bourtemb Ready for review. I've not done any automated modernization using clang-tidy/clang-modernize at this point as the PR is already big enough.

And I also did not want to step on everyones toes who has a PR open.

@bourtemb
Copy link
Member

What -std flag will be used for compilers that do not support c++14, e.g. gcc 4.8.1)? If I recall, -std=c++11 was never a default setting in gcc and if this is true, the compiler will run in c++98 mode, right? On Debian 8 we compile in c++14 mode so actually there is no job in CI that checks the c++11 mode.

I think
set(CXX_STANDARD_REQUIRED 11)
instruction in CMakeLists.txt is ensuring the code is compiled with at least c++11 enabled.
https://cmake.org/cmake/help/v3.1/prop_tgt/CXX_STANDARD.html#prop_tgt:CXX_STANDARD

@t-b
Copy link
Collaborator Author

t-b commented Jan 22, 2020

I'm not 100% sure that set(CXX_STANDARD_REQUIRED 11) will really fail cmake if it the compiler does not understand c++11. But something like the check in #659 does enforce that. And that PR is planned to be merged after this one.

bourtemb
bourtemb previously approved these changes Jan 22, 2020
Copy link
Member

@bourtemb bourtemb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @t-b for this big PR cleaning up the current code after the decision taken to require C++11 support.
This PR looks good to me as it is now.
It has an impact on a big number of files so this will cause some issues with the other PRs currently being merged which will have to be rebased and conflicts may appear.
I think we should not wait too much before merging this one because it will become quickly a nightmare to keep it up to date otherwise.

@t-b t-b requested a review from mliszcz January 22, 2020 14:39
@t-b
Copy link
Collaborator Author

t-b commented Jan 22, 2020

@mliszcz I would merge this one after #640 as your PR is older.

@mliszcz
Copy link
Collaborator

mliszcz commented Jan 22, 2020

@t-b Thanks! I've merged the mentioned PR. There is a minor conflict in travis configuration though.

mliszcz
mliszcz previously approved these changes Jan 22, 2020
Copy link
Collaborator

@mliszcz mliszcz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Thanks!

t-b added 9 commits January 22, 2020 16:33
We don't use per target properties like cxx_std_11 as these are only
supported starting with cmake 3.8. So we set it globally instead.
This is way too old to work anymore as we now require C++11.
We now require C++11.

Done with unifdef -DHAS_UNIQUE_PTR
We now require C++11.

Done with unifdef -DHAS_MAP_AT
We now require C++11.

Done with unifdef -DHAS_OVERRIDE
We now require C++11.

Done with unifdef -DHAS_RVALUE
We now require C++11.

Done with unifdef -DHAS_THREAD
We now require C++11.

Done with unifdef -DHAS_TYPE_TRAITS
We now require C++11.

Done with unifdef -DHAS_LAMBDA_FUNC
t-b added 19 commits January 22, 2020 16:33
We now require C++11 so nullptr is always available. But we keep the
definitions of Tango_nullptr for backwards compatibility.
We now require C++11.

Done with unifdef -DHAS_RANGE_BASE_FOR
We now require C++11.

Done with unifdef -DINIT_LIST
We now require C++11.

Done with unifdef -DHAS_UNDERLYING
…feature checking

We now always require C++11.
This is just too old as it has only GCC 4.7.2.
Exposed with the new C++11 compilation, but ultimately forgotten in
cc8f943 (cppapi/server: Ignore warnings for generated code,
2019-11-15).
Found with -Winconsistent-missing-override using latest clang 9.0.
The only C++ feature we are currently using which is not supported by
C++11 is C++14 relaxed constexpr.

Instead of using the old school ifdef magic we now use a real feature
test.

This also requires to move the definition of TANGO_CONSTEXPR to
tango_const.h.in.
We now output cmake/compiler and platform versions for easier debugging.
Output like the CMAKE_BUILD_TYPE was also changed to be outputted always
regardless if default or not.
MSVC versions prior to VS 2015 (aka msvc14) don't have usable C++11
support. So we can't build on those anymore.

This was also decided in  [2] which said:

> Decision was taken to stop support for MSVC9, MSVC10 and MSVC12. The
> builds for these MSVC compiler versions will be removed from appveyor.
> If some users still need to compile cppTango using these compilers, they
> will need to fork cppTango and maintain a version compatible with these
> old compilers.

[1]: https://docs.microsoft.com/en-us/previous-versions/hh567368(v=vs.140)?redirectedfrom=MSDN#featurelist
[2]: https://github.com/tango-controls/tango-kernel-followup/blob/master/2019-02-04/outcomes.md
Removed with unifdef -D_MSC_VER=1900 and manual fixup of false matches.

We also remove the predefined WIN32_VC* definitions as nobody is using
them.
Support for MSVC below 2015 (aka vc14 aka _MSC_VER 1900) was removed in
a previous commit.
We nowadays alwas mark Except::throw_exception as [[noreturn]] therefore
all compiler should be able to figure out that the function does not
need a return value here.
@t-b t-b dismissed stale reviews from mliszcz and bourtemb via 17abaed January 22, 2020 15:38
@t-b t-b force-pushed the require-c++11-and-cmake-3.7 branch from 100f45f to 17abaed Compare January 22, 2020 15:38
@t-b
Copy link
Collaborator Author

t-b commented Jan 22, 2020

@mliszcz @bourtemb Rebased.

@t-b t-b requested review from bourtemb and mliszcz January 22, 2020 15:39
@t-b t-b merged commit 81286b2 into tango-controls:tango-9-lts Jan 22, 2020
@t-b t-b deleted the require-c++11-and-cmake-3.7 branch January 22, 2020 20:10
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Raise required C++11 and cmake versions

3 participants