search

OSGeo / grass

GRASS GIS - free and open-source geospatial processing engine
https://grass.osgeo.org
Other
820 stars 302 forks source link

[Feat] Upgrade C++ standard support to C++17 #4040

Open nilason opened 1 month ago

nilason commented 1 month ago

Moving forward, it will be increasingly difficult to keep the C++ standard support of C++11. The required dependency GDAL 3.9+ (released in May 2024) and the important PDAL 2.4+ (released in Mars 2022) for example, are supporting C++17.

I propose to upgrade our C++ standard support to C++17: our code builds without changes in C++17 "mode", it will probably in first instance be a question of declaring our intention.

C++17 summary

echoix commented 1 month ago

Also see https://github.com/OSGeo/grass/pull/3846

veroandreo commented 1 month ago

We kinda already updated them de facto by removing older standards from CI build tests in #3846.

The next PSC meeting is on Aug 9th, I'll put this in the agenda. Now, do we really need a new RFC with a justification or can we just vote on updating the standards in the last section of the existing one?

nilason commented 1 month ago

Just want to clarify, we may keep the C++11 standard support as there are no urgent code changes planned (requiring C++17) or we do not hook up (if I'm not mistaken) GDAL C++ API (only C). Building GRASS GIS with PDAL support however, requires setting C++17 standard support. It is another question, how we set up the CI runners.

The next PSC meeting is on Aug 9th, I'll put this in the agenda. Now, do we really need a new RFC with a justification or can we just vote on updating the standards in the last section of the existing one?

I think a new RFC needs to be approved, which supersedes the current (cf. e.g. Python's https://peps.python.org/pep-0001/). (The RFC files should probably be prepended with the RFC number.)

veroandreo commented 1 month ago

Just want to clarify, we may keep the C++11 standard support as there are no urgent code changes planned (requiring C++17) or we do not hook up (if I'm not mistaken) GDAL C++ API (only C). Building GRASS GIS with PDAL support however, requires setting C++17 standard support. It is another question, how we set up the CI runners.

The next PSC meeting is on Aug 9th, I'll put this in the agenda. Now, do we really need a new RFC with a justification or can we just vote on updating the standards in the last section of the existing one?

I think a new RFC needs to be approved, which supersedes the current (cf. e.g. Python's https://peps.python.org/pep-0001/). (The RFC files should probably be prepended with the RFC number.)

Would you be willing to draft a new one then?

For the Python version support, the RFC states a rule to update the minimum version supported so we don't need to write a new RFC every time. Isn't there a way to do the same for C and C++? (Apologies if this is a silly question!)

nilason commented 1 month ago

I think a new RFC needs to be approved, which supersedes the current (cf. e.g. Python's https://peps.python.org/pep-0001/). (The RFC files should probably be prepended with the RFC number.)

Would you be willing to draft a new one then?

Sure, I will.

For the Python version support, the RFC states a rule to update the minimum version supported so we don't need to write a new RFC every time. Isn't there a way to do the same for C and C++? (Apologies if this is a silly question!)

Python has a predictable release schedule with a new release (and importantly an end-of-life version) every year. That makes it possible to follow on our side as per RFC 8. C/C++ standard is quite a different issue and I see no obvious way to "automate" this.

veroandreo commented 1 month ago

I think a new RFC needs to be approved, which supersedes the current (cf. e.g. Python's https://peps.python.org/pep-0001/). (The RFC files should probably be prepended with the RFC number.)

Would you be willing to draft a new one then?

Sure, I will.

Thanks!! :pray: