lmi
[Top][All Lists]
Advanced

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

Re: [lmi] PATCH: better way to suppress gcc7 warnings in Boost headers


From: Greg Chicares
Subject: Re: [lmi] PATCH: better way to suppress gcc7 warnings in Boost headers
Date: Wed, 18 Apr 2018 12:57:10 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-03-06 19:10, Vadim Zeitlin wrote:
[...]
>  I've created https://github.com/vadz/lmi/pull/73 doing it is very simple
> and so, hopefully, could be accepted,

Pushed a moment ago.

> but please notice that I did _not_
> test it using the official makefiles with MinGW as I didn't set up gcc 7 in
> my VM yet

Tested with MinGW-w64 gcc-7.3.0 here.

> (BTW, do you think it's worth keeping gcc 6 in it or is it not
> needed at all any longer?)

I hope we can expunge every trace of boost from lmi soon, and then this
header will no longer exist. Meanwhile, I would have accepted it without
emendation whether or not you had guarded it for gcc-7.

In general, I do retain some code and comments that pertain only to
obsolete compilers, just in case workarounds that had become unnecessary
become useful again later. For example, there's a comment in some unit
test concerning a curious anomaly seen with the old comeau compiler, and
years later we saw the same anomaly with valgrind. And some of the old
support for comeau might be useful if we ever use another EDG compiler,
but I recently deleted a makefile that installed comeau with its
dependency on gcc-2.95, because that won't apply to modern EDG tools.

OTOH, I tend to remove such things if they're clearly immaterial, as in
this case. We require 'std=c++17', so only gcc-7+ is acceptable. We'll
will never go back to an earlier gcc version, so the compiler-version
guard around these pragmata is just incidental and merely documents the
gcc version in which the referenced warnings were added--information
that has no enduring value. It's not worth changing here only because
this header should be purged soon.



reply via email to

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