Explicitly request CMake use gnu++17 over c++17

[robertmaynard]

Currently cudf requires compiler extensions to use __int128_t with standard library containers. Ensure the correct compilation flags are always providied.

[bdice]

Looks good. Would a comment be helpful, to indicate that extensions are only needed for 128 bit integer support?

[robertmaynard]

Looks good. Would a comment be helpful, to indicate that extensions are only needed for 128 bit integer support?

Good idea, done.

[codereport]

lgtm 👍

[codecov]

Codecov Report

Merging #10297 (5a72c87) into branch-22.04 (8b0737d) will decrease coverage by 0.00%.
The diff coverage is n/a.

@@               Coverage Diff                @@
##           branch-22.04   #10297      +/-   ##
================================================
- Coverage         10.67%   10.67%   -0.01%     
================================================
  Files               122      122              
  Lines             20874    20880       +6     
================================================
  Hits               2228     2228              
- Misses            18646    18652       +6     

Impacted Files	Coverage Δ
python/cudf/cudf/core/dataframe.py	0.00% <0.00%> (ø)
python/cudf/cudf/testing/_utils.py	0.00% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8b0737d...5a72c87. Read the comment docs.

[vyasr]

@robertmaynard do we anticipate support for this in libcudacxx at some known point in the future? Should we make a note somewhere that we would like to switch to relying on that when we can?

[vyasr]

I'm going to approve this in case it's blocking builds for the ops team, but if we plan to switch to relying on libcudacxx for int128 support at some point I would like that to be noted in the CMake so that we don't lose track of that.

[robertmaynard]

@robertmaynard do we anticipate support for this in libcudacxx at some known point in the future? Should we make a note somewhere that we would like to switch to relying on that when we can?

@vyasr Do you think the new comment is sufficient?

[vyasr]

Yup that looks good to me. I'm not aware of this being a high priority on the short term cuda::std roadmap so I don't think we can say anything more specific right now.

[robertmaynard]

@gpucibot merge