On 21/12/2017 1:02 PM, Winston Chang wrote:
On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
https://github.com/wch/r-source/commit/2e80059
That is not the canonical R sources.
Yes, that is obvious. The main page for that repository says it is a
mirror of the R sources, right at the top. I know that because I put
the message there, and because I see it every time I visit the
repository. If you have a good way of pointing people to the changes
made in a commit with the canonical R sources, please let us know. I
and many others would be happy to use it.
The usual way is just to refer to the revision number, i.e. "This
appears to have been added in rev 73909".
People who don't have the sources checked out can see the diff on your
Github mirror using
https://github.com/wch/r-source/search?q="trunk@73909"&type=Commits
and following the listed search hit. (Thanks to Thierry Onkelinx for
helping me with this.) This only works for commits to the trunk. I
guessed that something like
https://github.com/wch/r-source/search?q="R-3-4-branch@73937"&type=Commits
would work if the commit was to the 3.4 branch, but apparently not. I
don't know how to find those commits. Presumably there's a way, but I
don't know it.
Another possibility is that someone could set up (or already has?) one
of the web viewers (WebSVN, etc.) for the real repository. That would
be better for those of us who are SVN users, but probably harder for Git
users.
Duncan Murdoch
And your description seems wrong:
there is now an _optional_ check controlled by an environment variable,
primarily for CRAN checks.
The check is "optional", but not for packages submitted to CRAN.
I'm working on a package where these compiler warning flags are
present in a Makefile generated by a configure script -- that is, the
configure script detects whether the compiler supports these flags,
and if so, puts them in the Makefile. (The configure script is for a
third-party C library which is in a subdirectory of src/.)
Because the flags are added only if the system supports them, there
shouldn't be any worries about portability in practice.
Please read the explanation in the manual: there are serious concerns about
such flags which have bitten CRAN users several times.
To take your example, you cannot know what -Werror does on all compilers
(past, present or future) where it is supported (and -W flags do do
different things on different compilers). On current gcc it does
-Werror
Make all warnings into errors.
and so its effect depends on what other flags are used (people typically use
-Wall, and most new versions of both gcc and clang add more warnings to
-Wall -- I read this week exactly such a discussion about the interaction of
-Werror with -Wtautological-constant-compare as part of -Wall in clang
trunk).
Is there a way to get R CMD check to not raise warnings in cases like
this? I know I could modify the C library's configure.ac (which is
used to generate the configure script) but I'd prefer to leave the
library's code untouched if possible.
You don't need to (and most likely should not) use the C[XX]FLAGS it
generates ... just use the flags which R passes to the package to use.
It turns out that there isn't even a risk of these compiler flags
being used -- I learned from of my colleagues that the troublesome
compiler flags, like -Werror, never actually appear in the Makefile.
The configure script prints out those compiler flags out when it
checks for them, but in the end it creates a Makefile with the CFLAGS
inherited from R. So there's no chance that the library would be
compiled using those flags (unless R passed them along).
His suggested workaround is to silence the output of the configure
script. That also hides some useful information, but it does work for
this issue.
-Winston
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
