[Rd] R CMD check warning about compiler warning flags

[Duncan Murdoch]

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