lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Greg Chicares
Subject: Re: [lmi] [lmi-commits] master 048b530 1/4: Require compiler to provide operator<=>
Date: Tue, 11 May 2021 20:08:25 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0

On 5/9/21 4:06 PM, Vadim Zeitlin wrote:
> On Wed,  5 May 2021 12:35:14 -0400 (EDT) Greg Chicares 
> <gchicares@sbcglobal.net> wrote:
[...]
> GC> commit 048b5307d30e59cacd878664fcb12fdcf1b4571d
[...]
> GC>     Require compiler to provide operator<=>
[...]
>  This broke compilation with the gcc version used in the CI builds, see
> e.g. https://github.com/let-me-illustrate/lmi/actions/runs/824277618 which
> shows that all builds using gcc fail with the following error
> 
> ./gpt_commutation_functions.hpp:105:54: error: ‘bool 
> gpt_scalar_parms::operator==(const gpt_scalar_parms&) const’ cannot be 
> defaulted
>   105 |     bool operator==(gpt_scalar_parms const&) const = default;
>       |                                                      ^~~~~~~
> 
> as the gcc version used there (9.3) doesn't support this C++20 feature yet
[...]
>  I'd like to fix it a.s.a.p., but I wanted to confirm that we really don't
> need to support any pre-C++20 compilers

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

> I also wonder if you have any preferences about
> the compiler version to use in the CI builds, as I don't know yet what am I
> going to do about them: I could either try to set up a Debian Sid chroot to
> use exactly the same version as we do (which will be gcc 11 soon if it
> isn't already) or use the oldest still support version (10) or maybe even
> do both. Please let me know if you have any preferences.

Isn't it true that CI builds do nothing outside the union of
  nychthemeral_test.sh
  gui_test.sh
? Assuming that's the case, I already run both scripts before
pushing anything, so the CI builds are largely duplicative.
They're still valuable because they
 - use clang as well as gcc
 - use automake
 - use native msw as well as (or instead of) wine
 - always run even if I somehow neglect my usual checks
and perhaps for other reasons. But for testing gcc, they
probably don't add much if they use exactly the same version
of gcc I'm using; they'd add more if you use the latest version,
in case I haven't upgraded to it yet (not necessarily due to
sloth: upgrading from gcc-8 to gcc-10 did cause some numerical
regressions that had to be investigated).

So I guess a 'sid' chroot would be optimal; and, if that's easy,
I don't see any need for CI to use any other gcc version.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]