On Tue, 28 Jan 2025 at 09:07, Jakub Jelinek <ja...@redhat.com> wrote: > > On Mon, Jan 27, 2025 at 07:31:35PM +0000, Sérgio Basto via devel wrote: > > I just want check, if I'm thinking correctly before submitting a fix in > > gtest package > > > > The problem is on Rawhide I have this warning that make other packages > > fail to build [1] > > > > gtest source [2] source get __cplusplus value and include <version> or > > #include <ciso646> depending on __cplusplus value . > > > > On rawhide I got the warning on Fedora 41 don't but __cplusplus of GCC > > compiler is the same (201703) > > > > My proposal is to change the comparison from 202002L to 201703L > > -#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \ > > +#if GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \ > > That is not correct. <version> is actually not guaranteed to be there for > C++17, it was only added in https://wg21.link/p0754r2 in 2018 (so e.g. for > GCC since GCC 9.1). __has_include is supported by GCC since 2014 (so GCC > 5.1). So your change would break building with GCC 5.1 to 8.5. > I think if it did e.g. > #if (GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && \ > !defined(__has_include)) || \ > (GTEST_INTERNAL_CPLUSPLUS_LANG >= 201703L && \ > GTEST_INTERNAL_HAS_INCLUDE(<version>)) > #include <version> > #endif > it would be better, C++20 should guarantee there is <version> (but also > that __has_include is there, but this stuff attempts to cover also the cases > of the incremental development of the standard features). > I don't really see the point of including <ciso646>, it is a useless header > which doesn't contain anything since its introduction and has been removed > without deprecation in C++20. > I think the rationale some people give is that it is the smallest C++ header > (contains nothing) which still includes some basic header with some macros > (in the libstdc++ case it is <bits/c++config.h>, in libcxx case it is > <__config>). But e.g. in the libstdc++ case, that header doesn't really > define any feature test macros, the __cpp_* macros are predefined by the > compiler and __cpp_lib_* are defined by the individual headers which provide > that functionality or (when it exists) in <version>.
"Traditionally" <ciso646> was included to find out which C++ standard library implementation you were using, by including it and then checking for _LIBCPP_VERSION or _GLIBCXX_VERSION. So it's not supposed to be used for checking the standard __cpp_lib_xxx macros, but the implementation-specific ones. N.B. GCC's <ciso646> did not actually define _GLIBCXX_VERSION (or any other libstdc++ macros) until GCC 6.1, because it really did _nothing_ before that. It didn't even include <bits/c++config.h>. I second Jakub's suggestion to just include <version> if it's available. It's not required by the C++ standard until C++20, but given a sufficiently new compiler the <version> header is still present and can be included for older versions of C++. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
