[Rd] R CMD check warning about compiler warning flags

Martin Maechler maechler at stat.math.ethz.ch
Fri Dec 22 15:12:46 CET 2017

>>>>> Duncan Murdoch <murdoch.duncan at gmail.com>
>>>>>     on Thu, 21 Dec 2017 14:23:13 -0500 writes:

    > 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

As you know I had setup (the first few versions of) the svn at

at the time, I wanted to keep that machine protected as much as
possible and had decided not to install any other apache
modules and svn - niceties just such that the server would run
minimal services and hence would be minimally vulnerable.

The times have changed though and I will look into adding WebSVN
to svn.r-project.org  as one of the  first things in 2018.

Martin Maechler

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

    > ______________________________________________
    > R-devel at r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list