On Tue, 11 Feb 2025 at 22:44, Sérgio Basto <ser...@serjux.com> wrote: > > On Tue, 2025-02-11 at 21:45 +0000, Jonathan Wakely wrote: > > 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++. > > > > Hi, but if we are build in an "old" GCC , can we replace <ciso646> by > <cerrno> ? I also like the Jakub's suggestion [1] . Should/Can we > apply this suggestion also to abseil-cpp-20240722.1 ? > > [1] > #if GTEST_INTERNAL_HAS_INCLUDE(<version>) || \ > (GTEST_INTERNAL_CPLUSPLUS_LANG >= 202002L && > !defined(__has_include)) > #include <version> // C++20 and later > #else > #include <cerrno> // Pre-C++20 > #endif
I missed this follow-up question, sorry. Including <cerrno> would have equivalent effects to <ciso606>, except for also declaring all the contents of <errno.h> (which isn't very much, so mostly harmless). Before GCC 6.1 <cerrno> did not define the _GLIBCXX_xxx macros, but neither did <ciso646> so there's no difference between then in that respect. -- _______________________________________________ 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
