tech-pkg archive

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

Re: gdal 3.9.0, C++17, charconv, gcc7



Thomas Klausner <wiz%gatalith.at@localhost> writes:

> On Thu, Jun 06, 2024 at 04:19:41PM -0400, Greg Troxel wrote:
>> Would that leave charconv as "uses charconv, but in general does not
>> need c++17"?
>
> We already have a feature specific to charconv:
> USE_CXX_FEATURES+= charconv

We do, but we are in the strange situation where saying you need C++17
(because upstream says so) does not get you C++17, but some subset.  Not
only is this not documented, but the comments say that asking for a
language variant actually gets you that variant.

Besides having the documentation be accurate, there's a real mismatch
between the rest of the world which expects, naturally enough, "requires
C++17" to mean "a compiler that can compile all valid C++17 programs",
and pkgsrc, which means "a compiler that can compile some, except those
that can't, and we won't tell you which ones those are, and we don't
document what you need to ask for to make them all work".

I know that sounds cranky, but that's how I see at, coming from "read
upstream NEWS, set variables, and expect sound behavior".

Hence, I meant

  are we going to make C++17 means C++17

or

  are we going to document our Alice situation clearly, so that when
  someone reads C++17 in release notes, they can write

  USE_CXX_FEATURES= c++17 charconv other-secret-feature

instead?


Right now the straightforward approach leads to failing builds.


Maybe we should have c++17lite and map that as we do, but really to
commit something with that when upstream says c++17, one has to test
with the forced-by-c++17 version of each compiler, and no higher, and
that's basically impossible on NetBSD 10 or current.



Home | Main Index | Thread Index | Old Index