lmi
[Top][All Lists]
Advanced

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

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


From: Greg Chicares
Subject: Re: [lmi] PATCH: Fix build with gcc11 in C++20 mode
Date: Fri, 22 Oct 2021 14:44:18 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 10/21/21 11:18 PM, Vadim Zeitlin wrote:
[...]
>       https://github.com/let-me-illustrate/lmi/pull/193

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

>  But if you don't disagree too much, it would be nice to merge this in
> order to fix the CI builds.
> 
>  Which, BTW, does bring up another question: do we really want to use Sid
> for them?

Yes, I think so.

As the joke goes, for debian, 'testing' means stable, and 'stable' means old.
Our usage, at a glance:
- CI builds use 'sid' (i.e., 'unstable') today.
- Today, production uses 'bullseye' (which was 'testing' but became 'stable').
- We'd like to make production use 'bookworm' (which is now 'testing').

The original reason for using 'testing' was that it had significantly more
modern versions of tools we need (most crucially, g++) than 'stable'. AFAICT,
that's generally going to be the case.

The advantage of using 'unstable' for CI builds is that it often has even
more modern versions of crucial tools, so problems are detected even earlier.
The disadvantage is that an erroneous package in 'unstable' can break the CI
builds; but in practice, we aren't encountering that sort of problem. What we
are encountering is stricter enforcement of C++ rules that we want to follow,
and which we will need to follow once a new g++ moves to 'testing', and it's
good to find such breakage earlier.  

> We've started doing it because only Sid had the (cross) compiler
> recent enough for our needs, but we could switch to using the new stable
> Debian release (Bullseye) which has the same version of it as Sid right
> now (but still uses, and will keep using, gcc 10.2).

This page:
  https://packages.debian.org/search?keywords=mingw-w64
shows the same "8.0.0-1" version, today, for all debian releases we care
about. OTOH, for pc-linux-gnu:
  https://packages.debian.org/search?keywords=gcc
'stable' and 'testing' have "4:10.2.1-1", but unstable has "4:11.2.0-2".

I think you're asking whether we should lock that version for some
considerable length of time, say, a year or two, e.g. by choosing
'stable' for CI builds. Is that the question?

> Personally I think
> that we ought to switch to Bullseye as the official build platform,

For production here, we use 'bullseye' today, but plan instead to use
'bookworm' fairly soon. Do you suggest dropping that plan?

> and use
> it for the CI builds too, but we could still keep running the CI builds
> under Sid to learn in advance of any new breakages due to compiler updates.

I think it's advantageous to continue running CI builds under
'unstable', for the reason you gave. Then the question becomes what
debian release to use in two cases:
  (1) for production...why not move to 'bookworm'?
  (2) for non-unstable CI builds...shouldn't we use the same
      answer as for (1)? In particular, if we use 'bookworm' for
      production, why would we want anything older for CI?


reply via email to

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