Re: [lmi] [lmi-commits] master 048b530 1/4: Require compiler to provide operator<=>

[Vadim Zeitlin]

On Tue, 11 May 2021 20:08:25 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> Yes, C++20 is now the required minimum dialect.

 OK, thanks for confirming this, I've updated configure and almost finished
fixing CI but, unfortunately, am still struggling with some
permission-related problems (this might sound familiar to you from your
chroot setting up days) and probably won't finish until tomorrow.

GC> Isn't it true that CI builds do nothing outside the union of
GC>   nychthemeral_test.sh
GC>   gui_test.sh
GC> ?

 I think so, yes. The main (but huge, for me) advantage of it is that they
do it _before_ PRs are merged into master, allowing to notice any problems
before it's too late.

GC> Assuming that's the case, I already run both scripts before
GC> pushing anything, so the CI builds are largely duplicative.

 I don't think I'm going to be able to convince you that pushing your
branch and having these scripts run automatically is more convenient than
doing it manually locally, so I won't even try, but I'd just like to note
that these scripts main advantage is not that they do something unique and
original (in fact, I'd like them to be more duplicative and trivial), but
that they do it automatically and in many different build configurations in
parallel, thus saving effort and time.

GC> They're still valuable because they
GC>  - use clang as well as gcc
GC>  - use automake

 Yes.

GC>  - use native msw as well as (or instead of) wine

 This is not the case yet. But I'd like to set this up.

GC>  - always run even if I somehow neglect my usual checks
GC> and perhaps for other reasons. But for testing gcc, they
GC> probably don't add much if they use exactly the same version
GC> of gcc I'm using; they'd add more if you use the latest version,
GC> in case I haven't upgraded to it yet (not necessarily due to
GC> sloth: upgrading from gcc-8 to gcc-10 did cause some numerical
GC> regressions that had to be investigated).
GC> 
GC> So I guess a 'sid' chroot would be optimal; and, if that's easy,
GC> I don't see any need for CI to use any other gcc version.

 I've set the CI builds to use the official Debian Sid Docker container
(which is kind of a chroot, but much simpler to integrate with just about
anything), which means that currently they use the following compilers
(I've also added this information to the CI logs):

- i686-w64-mingw32-gcc (GCC) 10-win32 20210110
- gcc (Debian 10.2.1-6) 10.2.1 20210110
- Debian clang version 11.0.1-2

 We could also very easily use gcc 11 and/or clang 12 from Experimental if
we wanted.

 Thanks again for your answers and I should have the changes fixing CI
soon. I could almost merge them myself, as they only touch "my" files, if
not for this change:

---------------------------------- >8 --------------------------------------
commit 270aaa6ab1bd89bcf781d1c08d1662b2de447973
Author: Vadim Zeitlin <vadim@tt-solutions.com>
Date:   2021-05-11 17:51:35 +0200

    Add workaround for Boost.Regex compilation with clang 11

    std::allocator::size_type is used, even when BOOST_NO_STD_ALLOCATOR is
    defined, in boost/regex/v4/match_results.hpp, but libc++ used by clang
    11 doesn't define this type in C++20 mode, so explicitly request it to
    still be defined even in this case.

diff --git a/boost_regex.hpp b/boost_regex.hpp
index c69fc7ebd..a273cb271 100644
--- a/boost_regex.hpp
+++ b/boost_regex.hpp
@@ -32,6 +32,14 @@
 #   pragma clang diagnostic ignored "-Wkeyword-macro"
 #   pragma clang diagnostic ignored "-Wparentheses-equality"
 #   pragma clang diagnostic ignored "-Wregister"
+
+    // libc++ used by clang 11 requires defining this symbol in order to define
+    // std::allocator::size_type, which is still used by Boost code even when
+    // BOOST_NO_STD_ALLOCATOR is defined. Surprisingly, this type definition is
+    // unconditional in libc++ 12, so this might have been a mistake in this
+    // particular libc++ version, but it's still simpler to work around it
+    // unconditionally rather than try to detect the exact libc++ version.
+#   define _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS
 #endif // defined LMI_CLANG
 #if defined LMI_GCC
 #   pragma GCC diagnostic push
---------------------------------- >8 --------------------------------------

But if you don't mind me pushing this too, I could still do it on my own
(notice that this change is inside "#ifdef LMI_CLANG" and so doesn't affect
production builds). Please let me know if I should just do this or if you'd
like to review the changes.

 Thanks again,
VZ

pgprkRlh5rm4C.pgp
Description: PGP signature