This also doesn't answer your question, but:
A trick that the TMB package uses to help users is to suggest that they
add "CXXFLAGS += -Wno-ignored-attributes" to their `.R/Makevars` file.
This means that *they* don't have to see useless warnings when compiling
code.
In your case I don't know if there is a compiler flag that is
equivalent to your pragma, or you could add your own macro/#ifdef
(CXXFLAGS += -DSUPPRESS_WARNINGS) so that *you* don't have to see the
warning messages. (If CRAN doesn't want to see all the warnings that's
their problem ...)
On 2023-08-14 8:59 a.m., Mark Padgham wrote:
On 14/08/2023 14:43, Dirk Eddelbuettel wrote:
On 14 August 2023 at 11:51, Mark Padgham wrote:
| An update of a package of mine got immediately kicked off CRAN because
| an externally-bundled file which had not been changed for years, and
| which included "pragma clang system_header" to suppress warnings. The
| concern is fair enough. Removing that nevertheless now generates a heap
| of warnings which CRAN will have to wade through / grep to assess
| whether any are of concern. These can be easily suppressed by replacing
| cheap "system_header" with targeted suppression of just two classes of
| warnings for that bundled header file only. But I guess this is also
| forbidden? Should I now just leave those warnings, and rely on CRAN's
| grep policies to assess them? Is there any public list of what such
grep
| policies might be? (And no, I can't adapt the code to remove the
| warnings, because most are "zero-as-null-pointer-constant", but the "0"
| is actually better than nullptr the way the code is constructed. The
| rest are - currently - unimportant deprecation warnings, all of one
| specific class.)
It is in the CRAN Repostory Policy:
- Packages should not attempt to disable compiler diagnostics, nor to
remove other diagnostic information such as symbols in shared
objects.
Per 'svn blame' it goes back to commit 4049 from Apr 2019, but a
commit from
Nov 2017 has 'memtion (sic!) not disabling compiler diagnostics'.
FWIW I have had to do it for BH and RcppEigen for some time leading to
both
of them 'spamming' package users with a lot of noise. I don't
particularly
like that, but I also do not have too many choices here.
Dirk
Thanks Dirk! I've seen also that a couple of tidyverse and r-lib pkgs
bundle the same header, and they also do nothing to suppress this
compiler spam. But gee it would be good to have some "official"
reference for what compiler warnings CRAN are likely to complain about,
and which ones they'll ignore!
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
--
Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of
working hours.
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
