>> 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
Duncan Murdoch
2017-Dec-21 19:23 UTC
[Rd] R CMD check warning about compiler warning flags
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 >
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}}
Martin Maechler
2017-Dec-22 14:12 UTC
[Rd] R CMD check warning about compiler warning flags
>>>>> 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 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 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