GH-49176: [C++] CRAN build fail on missing std::floating_point concept

[jonkeane]

Rationale for this change

Passing builds on CRAN

What changes are included in this PR?

A workaround for C++20 compatibility issues

Are these changes tested?

Yes, we can ship these tests in this PR or we can keep them in #49216 either is fine by me.

Are there any user-facing changes?

No

• GitHub Issue: [C++] CRAN build fail on missing std::floating_point concept #49176

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 5ed5de1

Submitted crossbow builds: ursacomputing/crossbow @ actions-bc3fd4369a

Task	Status
test-r-macos-as-cran

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 1314042

Submitted crossbow builds: ursacomputing/crossbow @ actions-cf07311e56

Task	Status
test-r-macos-as-cran

[jonkeane]

cc @shashbha14 here is a fix (+ a CI job that proves it)

[jonkeane]

Downloading this from this github site is very funky, and honestly a little sketchy. But it does actually replicate the very old macosx sdks that CRAN is building arrow with. And we can replicate it in CI

[pitrou]

Do you have a timeline on when we can remove this?

[jonkeane]

The R-devel runners are already moved to a newer version of the SDK, and R4.6 should be released in April (historically that's when that happens, but technically there isn't a set deadline). I don't yet know if that will mean all of CRAN's builders will have that new SDK though. I imagine they will move forward soon given how old these are, but in that thread there is a stated desire to keep supporting macOS + x86, which will

FWIW: I am honestly moderately uncomfortable with this, even in a CI job that has restricted permissions, etc. etc. But I haven't found any other way to link against the old SDKs that CRAN is using. We could make this something that is only run manually (though there is at least one other issue that has been merged to main that the old SDKs aren't good with: #49223 / #49105

I wonder if from ^^^ you have any ideas about how else we might catch when we need a fallback?

[pitrou]

cc @kou about the CI aspect of this

[jonkeane]

Not sure if this is helpful, but I did find https://developer.apple.com/xcode/cpp/#c++20 which lists when some of these features were supported (though not particularly consistently!) and once we are on xcode 14, it looks like we should be clear.

[pitrou]

Do we have some place we could host this privately (but still with access for our CI runners)? I'm happy to do that temporarily, but don't want it to be out and available on the open internet if possible. I would consider a private repo alongside usracomputing/crossbow, but I don't have access to that anymore. Do you know who does?

Perhaps @rok @raulcd @assignUser have ideas

[rok]

Does this need to be private? We have s3://arrow-data for things like nightly report.
We can make s new s3 bucket that's only accessible to our (self-hosted) CI runners?

[jonkeane]

Do we have any macos self-hosted runners? If yes, then just let me know where to put it and how to point this CI at those and I'll make it so...

[jonkeane]

Ok I have changed this to point to a (private) repo and added a limited PAT to crossbow for just that repo.

[jonkeane]

Oops, sorry when I commented I hadn't pushed yet, but it is now.

[shashbha14]

Thanks for working through this and wiring up the macOS-as-CRAN CI job, this makes the situation much clearer.
My earlier attempt on #49176 was just switching to std::is_floating_point_v, but your PR plus the SDK-based CI reproducer is a much more complete solution for the CRAN builders.
I’ll treat this PR as the canonical fix for the issue and won’t push additional changes on top of it unless you’d like help with anything specific.

[jonkeane]

@github-actions crossbow submit test-r-macos-as-cran

[github-actions]

Revision: 08daa2e

Submitted crossbow builds: ursacomputing/crossbow @ actions-ca0a264fc8

Task	Status
test-r-macos-as-cran

[jonkeane]

This is ready for (re)-review. If we are going to merge the CI changes (from #49216) we should merge them here, (though we will also need to merge #49223 to have this not fail on main once it is merged, but that's ok cause these are nightly tests)