[R] R package has a note about suppressed diagnostics on CRAN

[paleolimbot]

Describe the bug, including details regarding any error messages, version, and platform.

The NOTE from CRAN:

Version: 10.0.1
Check: compilation flags used
Result: WARN
    Compilation used the following non-portable flag(s):
     ‘-Wall;-Wextra;-Wno-unknown-pragmas;-fvisibility=hidden;-Wstrict-prototypes;-ftls-model=local-dynamic’
     ‘-Wno-noexcept-type’ ‘-msse4.2’
    including flag(s) suppressing warnings 

https://cran.r-project.org/web/checks/check_results_arrow.html

This is odd because usually we suppress that output on CRAN. CRAN may be doing some extra environment variable stuff to make these message print out. We may need to revisit the code where we turn off the compiler output to make sure they are suppressed (or we may have to negotiate with CRAN regarding compiler warnings).

Component(s)

R

[thisisnic]

How/where do we suppress this? Given this has only come up in 10.0.1 where we were experimenting with the new release checklist, it'd be good to rule out if there's a step missing, was missed, or something different in my setup compared to Neal's.

[paleolimbot]

I believe what happened is that CRAN set ARROW_R_DEV=true on one or more of its check machines, which means the verbose install logs got printed when building the vendored arrow. That may have been in good faith - to display as many warnings/errors as possible when running checks like gcc13 that are difficult/impossible to replicate otherwise - or it may be that they are planning to force the arrow package in line with the CRAN policy.

I think we should submit without changing anything and hope that it was the former...if CRAN has decided to enforce all of its policies on the arrow package, any attempt to actively circumvent that would be seen poorly (and probably wouldn't work anyway since they'd be manually inspecting changes).

[nealrichardson]

It's a silly policy for us because we use cmake to detect which compiler flags are valid to use on the current system. Hardcoding them would be dangerous, but that's not what we do.

[thisisnic]

I'm closing this as this doesn't seem to have caused us any problems with releases, but feel free to re-open if necessary.

[nealrichardson]

I don't see it on the current checks page, FWIW, so maybe they temporarily set ARROW_R_DEV to debug that previous failure.