[Rd] R CMD check warning about compiler warning flags

[Martin Morgan]

On 12/21/2017 01: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.

In case 'pointing to' is not to mean exclusively 'pointing a mouse at', 
'a good way' can include typing at the console and living with the 
merits and demerits of svn, and the question is not 
rhetorical....(probably FALSE on all accounts, but one never knows...)

Check out or update the source (linux, mac, or Windows)

   svn co https://svn.r-project.org/R/trunk R-devel
   cd R-devel
   svn up

browse the commit history

   svn log | less

and review the change

   svn diff -c73909

Restrict by specifying a path

   svn diff -c73909 src/library/tools/R/check.R

(I don't think one gets finer resolution, other than referencing the 
line number in the diff)

View a range of revisions, e.g.,

   svn diff -r73908:73909

And find commits associated with lines of code

   svn annotate doc/manual/R-exts.texi | less

A quick google search (svn diff visual display) lead me to

   svn diff --diff-cmd meld -c73909

for my platform, which pops up the diffs in a visual context.

Martin Morgan

> 
>> 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 at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 


This email message may contain legally privileged and/or...{{dropped:2}}