Re: [lmi] Dealling with gcc -dumpversion inconsistency

[Greg Chicares]

On 2020-10-07 17:01, Vadim Zeitlin wrote:
> 
>  This is a minor annoyance rather than a serious problem, but building
> under Linux currently always results in a couple of warnings like this:
> 
> /opt/lmi/src/lmi/workhorse.make:164: Untested cpp version '8'
> /opt/lmi/src/lmi/workhorse.make:182: Untested g++ version '8'

I didn't realize gcc-8 is still current for debian-stable:
  https://packages.debian.org/buster/gcc
Because you're using it, I'll add it to the 'tested' lists.

> I know that you're aware about it, because you've partially addressed it in
> 58c0d7cc9 (Allow exact gcc version "9" for x86_64-pc-linux-gnu, 2020-09-26)
> and more recent e73c066d8 (Allow gcc version "10" as well as "10.0",
> 2020-10-04), but I don't think this is sufficient, even disregarding the
> typo in the latter commit, which used gnu_cpp_version in both tests, when
> it should have been using gnu_cxx_version in the second one.

I've fixed that typo and one or two other things now.

>  The reason is that the problem is not specific to gcc-10, but also happens
> with gcc-8 and 9. In fact, gcc under Linux has apparently switched to
> reporting only the major version in -dumpversion since version 7.

The old behavior is available with a new '-dumpfullversion'
option, but the old option produces a new behavior, depending
on how gcc was built. That weird set of decisions ensures
backward incompatibility. Someone online suggested using both:
  gcc -dumpfullversion -dumpversion
on the assumption that gcc ignores '-dump' options that it
doesn't recognize. It seems strange to work around a backward
incompatibility in a way that relies on backward compatibility,
but if that actually works for all old versions that can still
be used for our C++17 code, maybe we should use it.

>  I am not sure what's going on with Linux gcc, but it would be nice to
> avoid the warnings for all versions without having to account for each of
> them individually. I see a few ways to do it, listed below in my personal
> order of preference (from best to worst):

If we were going to redesign the whole thing, I'd be more
receptive to major changes. Today, though:

https://lists.nongnu.org/archive/html/lmi/2007-03/msg00008.html
| Operations of thought are like cavalry charges in
| battle--they are strictly limited in number, they require
| fresh horses, and must only be made at decisive moments.

I'm radically redesigning the way string data are stored in
proprietary product files, and trying to figure out what to
do with "currency"; I hope I have enough fresh horses to
bring those projects off by the end of the year, but I'm
sure I haven't any to spare to redesign this too.

> 1. Just remove the version checks: it's somewhat strange to have 28 lines
>    doing them in the makefile, when more than half of them test for the
>    compilers not supported any longer and I honestly don't see what do they
>    bring.

They encourage positive habits, for me at least. When I see one
of those warnings, I enable that version, and test carefully for
regressions; then I adapt to the new behavior as necessary.

> 2. Check just the major version: this would be both shorter and more useful
>    IMO, as we could just test that the version is in [8, 10] interval.

Soon, though, we'll be testing for [10, whatever) because of
std::filesystem.

> 3. Switch to using `gcc --version|head -n1|sed whatever-it-takes` to
>    extract the full version. There is a lot of variety in the format
>    here, but it does always have major.minor.micro version number at
>    least once in it.

I tried to do that once, but recoiled in horror at the
version-dependent inconsistencies. Maybe
  gcc -dumpfullversion -dumpversion
does what '-dumpversion' was always supposed to do until they
broke it. Or we can just wait until we require gcc-10 for
std::filesystem, and use '--dumpfullversion' to test for it
and future releases.

> Of course, there is also always the choice
> 
> 0. Not do anything about this and/or keep adding more versions explicitly.

I'm afraid it's a case of:

https://www.lexico.com/definition/unravel
| There are some threads that once pulled unraveled the whole sweater.

Earlier today I pulled on some 'configurable_settings.xml'
threads, and the outcome was as predicted by that folk wisdom,
no matter how hard I tried to rebase my commits to make it look
as though I had some kind of plan. But that had to be changed;
this actually doesn't. I'll turn off the 'make' warnings for
exact version "8", though I don't plan to test that version
on pc-linux-gnu myself.