On Tue, 2025-02-11 at 21:45 +0000, Jonathan Wakely wrote: > On Tue, 28 Jan 2025 at 09:07, Jakub Jelinek <jakub@xxxxxxxxxx> 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 -- Sérgio M. B. -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
