Re: [lmi] PATCH: Fix build with gcc11 in C++20 mode

[Vadim Zeitlin]

On Fri, 22 Oct 2021 14:44:18 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 10/21/21 11:18 PM, Vadim Zeitlin wrote:
GC> [...]
GC> >   https://github.com/let-me-illustrate/lmi/pull/193
GC> 
GC> I'm studying this now.

 Thanks!

GC> Let me pose a high-level question: do you know
GC> whether the g++11 warnings that you're fixing here can conveniently be
GC> reproduced with the pc-linux-gnu g++ that I already have in a non-'sid'
GC> chroot, possibly by modifying some compiler options? (It would be nice
GC> if I could see them myself, but I'd rather not use install sid's gcc.)

 I'm afraid you really need gcc 11 or clang 12 (which is much older than
gcc 11, but still is only in Sid, I think), to see them, they just weren't
implemented in the previous versions.

GC> >  Which, BTW, does bring up another question: do we really want to use Sid
GC> > for them?
GC> 
GC> Yes, I think so.

 OK, thanks.

GC> As the joke goes, for debian, 'testing' means stable, and 'stable' means 
old.
GC> Our usage, at a glance:
GC> - CI builds use 'sid' (i.e., 'unstable') today.
GC> - Today, production uses 'bullseye' (which was 'testing' but became 
'stable').
GC> - We'd like to make production use 'bookworm' (which is now 'testing').
GC> 
GC> The original reason for using 'testing' was that it had significantly more
GC> modern versions of tools we need (most crucially, g++) than 'stable'. 
AFAICT,
GC> that's generally going to be the case.

 Yes, but perhaps less so than in the past as there was much less time
between the last 3 Debian releases than between the releases before them.
Of course, this could change again.

GC> The advantage of using 'unstable' for CI builds is that it often has even
GC> more modern versions of crucial tools, so problems are detected even 
earlier.
GC> The disadvantage is that an erroneous package in 'unstable' can break the CI
GC> builds; but in practice, we aren't encountering that sort of problem.

 It's a question of semantics, but in practice it seems that we do.

GC> What we are encountering is stricter enforcement of C++ rules that we
GC> want to follow, and which we will need to follow once a new g++ moves
GC> to 'testing', and it's good to find such breakage earlier.  

 Yes, I agree, but it's bad that we lose the possibility to detect other
problems (that the CI is supposed to detect) until such breakage is fixed.
Which is why I thought about running them in a stable environment too, in
which any breakage could be really blamed on the changes in the code and
not on the changes in Sid itself.

GC> > We've started doing it because only Sid had the (cross) compiler
GC> > recent enough for our needs, but we could switch to using the new stable
GC> > Debian release (Bullseye) which has the same version of it as Sid right
GC> > now (but still uses, and will keep using, gcc 10.2).
GC> 
GC> This page:
GC>   https://packages.debian.org/search?keywords=mingw-w64
GC> shows the same "8.0.0-1" version, today, for all debian releases we care
GC> about.

 I think a more relevant link is

        https://packages.debian.org/search?keywords=g%2b%2b-mingw-w64

which shows that it's 10.2 in Bullseye and Bookworm (and Sid too) right
now.

GC> OTOH, for pc-linux-gnu:
GC>   https://packages.debian.org/search?keywords=gcc
GC> 'stable' and 'testing' have "4:10.2.1-1", but unstable has "4:11.2.0-2".
GC> 
GC> I think you're asking whether we should lock that version for some
GC> considerable length of time, say, a year or two, e.g. by choosing
GC> 'stable' for CI builds. Is that the question?

 Yes, exactly.

GC> > Personally I think that we ought to switch to Bullseye as the
GC> > official build platform,
GC> 
GC> For production here, we use 'bullseye' today, but plan instead to use
GC> 'bookworm' fairly soon. Do you suggest dropping that plan?

 Sorry, I was simply confused and somehow missed/forgot about the switch to
Bullseye for production. Please disregard this part, sorry again.

GC> I think it's advantageous to continue running CI builds under
GC> 'unstable', for the reason you gave. Then the question becomes what
GC> debian release to use in two cases:
GC>   (1) for production...why not move to 'bookworm'?

 The only reason I see is that right now we don't need it and stable is,
well, stable.

GC>   (2) for non-unstable CI builds...shouldn't we use the same
GC>       answer as for (1)? In particular, if we use 'bookworm' for
GC>       production, why would we want anything older for CI?

 We wouldn't. But we would almost certainly want to run CI in both Bookworm
and Sid environments, to give us an advance warning of the problems that
are going to appear in the former, wouldn't we?

VZ

pgpBBq1fIc5NT.pgp
Description: PGP signature