R devel - Dec 2017 - R CMD check warning about compiler warning flags

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

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.

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.

-Winston

On 20/12/2017 17:42, 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.  And your description seems wrong: 
there is now an _optional_ check controlled by an environment variable, 
primarily for CRAN checks.
> 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.
> 
> -Winston
-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford

On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley
<ripley at stats.ox.ac.uk> wrote:
> On 20/12/2017 17:42, 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.  And your description seems wrong:
> there is now an _optional_ check controlled by an environment variable,
> primarily for CRAN checks.
Are the canonical R sources made available in such a way that one can
link to them?

Hadley

-- 
http://hadley.nz

>> 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.
> 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