>>>>> Duncan Murdoch <murdoch.dun...@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@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 As you know I had setup (the first few versions of) the svn at https://svn.r-project.org/ 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@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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel