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
"J. Lewis Muir" <jlmuir%imca-cat.org@localhost> writes:
> It doesn't seem quite right to me that pkgsrc allows putting both a
> language standard and features in USE_CXX_FEATURES.
>
> For example:
>
> USE_CXX_FEATURES= c++17 filesystem
Setting aside "feature foo is in N but we think it isn't", this is
really ok; you might need a compiler that does c++NN, and you might need
foo, for some foo NOT in NN but later). If this were
USE_CXX_FEATURES= c++11 filesystem
then I see nothing wrong with it.
> If the standard is supposed to have the feature, then listing the
> feature seems redundant.
"redundant" is not the issue. It's a disagreement between
c++17 means what it says, within reason
c++17 means a big enough subset that "most" programs that say they
need c++17 build, and the things that are in c++17 but not needed for
"most" are in features. (And some seem to think it's ok not to
document this, if I am following the comments, but I find it hard to
believe.)
> It seems that one of the following would be better:
>
> 1. Allow USE_CXX_FEATURES to contain either one standard or one or more
> features, but not both.
No, because "c++11 filesystem" is legit.
> 2. Add USE_CXX_STD that can be set to one standard, and allow
> USE_CXX_FEATURES to contain only features, not a standard. For
> example:
>
> USE_CXX_STD= c++17
That won't help anything, because there are just a bunch of (to write it
in pseudopython):
if foo in USE_CXX_FEATURES:
GCC_REQD+=10
And, a package might need to run a compiler with --std=c++11 and also
with --std=c++17 and having both documents that it needs a compiler that
can be called either way. Not that we have a compiler that does c++17
and not c++11, but there is no conceptual bug in stating that you need
both.
There is no practical problem blurring C++NN and features. Nobody is
confused by this. The only problem is the disagreement about whether
c++17 means "the entire standard, except perhaps for bizarre corner
cases that nobody uses and gcc does not implement", "almost all of it,
leaving out only things that are truly rare", or "most of it, but
leaving out things that are fairly normal these days".
I (and Patrick Welche, if I read right) think that charconv and
filesystem should be part of what you get with c++17. I am ok with
leaving parallelism_ts out for now, because we have 1 package that needs
it, and I only learned it exists today; I don't know what others think.
charconv and filesystem together with "pick limited versions" lead to
"c++17 needs gcc10" and then parallelism_ts is probably ok anyway.
I think the number of people on 9 that can get away without building
gcc10 and also build at least one program needing C++17 is very small.
If you are an actual such person, please speak up.
- References:
- gdal 3.9.0, C++17, charconv, gcc7
- Re: gdal 3.9.0, C++17, charconv, gcc7
- Re: gdal 3.9.0, C++17, charconv, gcc7
- Re: gdal 3.9.0, C++17, charconv, gcc7
- Re: gdal 3.9.0, C++17, charconv, gcc7
- Re: gdal 3.9.0, C++17, charconv, gcc7
- Re: gdal 3.9.0, C++17, charconv, gcc7
- Re: gdal 3.9.0, C++17, charconv, gcc7
Home |
Main Index |
Thread Index |
Old Index