R CMD check warning about compiler warning flags

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

R CMD check warning about compiler warning flags

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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Prof Brian Ripley
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,                  [hidden email]
Emeritus Professor of Applied Statistics, University of Oxford

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

hadley wickham
On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley
<[hidden email]> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Duncan Murdoch-2
On 20/12/2017 5:48 PM, Hadley Wickham wrote:

> On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley
> <[hidden email]> 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?

Yes, the sources are available.  To link to revision 73909 of R on the
trunk branch (which I think is the one referred to above), use

https://svn.r-project.org/R/trunk/?r=73909

I'm not sure if there's an easy way to see the diff between that and
73908 (which is what the github link showed).  I also don't know if
there's a way to show the diff between commit N and N-1 in github if I
only know N.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Duncan Murdoch-2
On 20/12/2017 6:52 PM, Duncan Murdoch wrote:

> On 20/12/2017 5:48 PM, Hadley Wickham wrote:
>> On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley
>> <[hidden email]> 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?
>
> Yes, the sources are available.  To link to revision 73909 of R on the
> trunk branch (which I think is the one referred to above), use
>
> https://svn.r-project.org/R/trunk/?r=73909
>
> I'm not sure if there's an easy way to see the diff between that and
> 73908 (which is what the github link showed).  

After checking a bit online, it appears there are projects WebSVN, USVN
and ViewVC that should do this. I don't know if anyone has set up views
of the R repository with any of those.  I've never used them, I just use
local tools.  In the past I used Windows-only TortoiseSVN (and it is
still one of the most attractive features of Windows); now I use RStudio
or command line svn.  As you know, RStudio's interface is somewhat
limited, and as far as I know it can't display features of remote
repositories.

I also don't know if
> there's a way to show the diff between commit N and N-1 in github if I
> only know N.

I still don't know this.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Winston Chang
In reply to this post by Prof Brian Ripley
>> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Duncan Murdoch-2
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


>
>> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Martin Morgan-3
In reply to this post by Winston Chang
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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>


This email message may contain legally privileged and/or...{{dropped:2}}

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Martin Maechler
In reply to this post by Duncan Murdoch-2
>>>>> Duncan Murdoch <[hidden email]>
>>>>>     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
    >>
    >> ______________________________________________
    >> [hidden email] mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >>

    > ______________________________________________
    > [hidden email] mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Marc Schwartz-3
Hi,

See inline below.


> On Dec 22, 2017, at 9:12 AM, Martin Maechler <[hidden email]> wrote:
>
>>>>>> Duncan Murdoch <[hidden email]>
>>>>>>    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


Martin,

Just to play a bit of a devil's advocate here, WebSVN has not been updated/maintained since June of 2011, so is a number of years old at this point. That should raise some reasonable concerns over bugs, security issues and related matters.

To put that in perspective, the last update to WebSVN was around the time that R 2.13.1 was released.

That general pattern, of SVN clients not being actively maintained, seems to be consistent across a number of the web based (and even browser plugin based) SVN clients, which may in turn, be an indication of the general shift to Git in recent years, much as the shift from CVS to SVN occurred years ago.

In researching other SVN clients, the few that still seem to be actively maintained are typically dedicated desktop clients/GUIs, that in some cases are closed source and/or are OS specific.

One of the few web based SVN clients that still seems to be actively maintained is Trac (https://trac.edgewall.org), however it is under a modified BSD license, which may raise some issues and from what I can tell, may be more complicated in terms of set up, since it also supports bug tracking, wiki and other functionality. As with any such application, there would be ongoing maintenance issues as well.

I am not advocating any particular solution. I just want to point out potential issues with WebSVN and raise for discussion, what options may make sense to consider, based upon how many folks might actually use such "live" web based functionality versus remote SVN access via a desktop client, which is certainly an option, since they won't have write access anyway.

Also, a number of the Git desktop clients also support Git SVN (https://git-scm.com/docs/git-svn), for compatibility, which offers Git users an alternative to using a dedicated desktop SVN client.

Regards,

Marc


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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Duncan Murdoch-2
On 22/12/2017 10:46 AM, Marc Schwartz wrote:

> Hi,
>
> See inline below.
>
>
>> On Dec 22, 2017, at 9:12 AM, Martin Maechler <[hidden email]> wrote:
>>
>>>>>>> Duncan Murdoch <[hidden email]>
>>>>>>>     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
>
>
> Martin,
>
> Just to play a bit of a devil's advocate here, WebSVN has not been updated/maintained since June of 2011, so is a number of years old at this point. That should raise some reasonable concerns over bugs, security issues and related matters.
>
> To put that in perspective, the last update to WebSVN was around the time that R 2.13.1 was released.
>
> That general pattern, of SVN clients not being actively maintained, seems to be consistent across a number of the web based (and even browser plugin based) SVN clients, which may in turn, be an indication of the general shift to Git in recent years, much as the shift from CVS to SVN occurred years ago.
>
> In researching other SVN clients, the few that still seem to be actively maintained are typically dedicated desktop clients/GUIs, that in some cases are closed source and/or are OS specific.
>
> One of the few web based SVN clients that still seems to be actively maintained is Trac (https://trac.edgewall.org), however it is under a modified BSD license, which may raise some issues and from what I can tell, may be more complicated in terms of set up, since it also supports bug tracking, wiki and other functionality. As with any such application, there would be ongoing maintenance issues as well.

There's also ViewVC which still seems to be active.

> I am not advocating any particular solution. I just want to point out potential issues with WebSVN and raise for discussion, what options may make sense to consider, based upon how many folks might actually use such "live" web based functionality versus remote SVN access via a desktop client, which is certainly an option, since they won't have write access anyway.

As a general principle in open source projects the work should be done
by the people who want to use the product.  Winston wanted git access to
the R sources, and he put it together: bravo!

It's unfortunate that git doesn't really support svn completely, because
it is superior in many ways.  However, it isn't uniformly better than
svn. Its very weak support for sequential labels means that switching to
it would be a lot of work for R Core, and that group doesn't have a lot
of spare time to waste.

The one negative aspect of Winston's effort is caused by this weakness.
If you tell me that something happened in revision 73909, I know it was
recent.  If you tell me that something appeared in commit 2e80059, it
wastes my time looking up that commit and putting it in context.

Duncan Murdoch

>
> Also, a number of the Git desktop clients also support Git SVN (https://git-scm.com/docs/git-svn), for compatibility, which offers Git users an alternative to using a dedicated desktop SVN client.
>
> Regards,
>
> Marc
>
>
>>
>>>>
>>>>> 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
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Iñaki Úcar
2017-12-25 12:30 GMT+01:00 Duncan Murdoch <[hidden email]>:
> The one negative aspect of Winston's effort is caused by this weakness. If
> you tell me that something happened in revision 73909, I know it was recent.
> If you tell me that something appeared in commit 2e80059, it wastes my time
> looking up that commit and putting it in context.

The output from "git describe" is something similar to an svn
revision: it describes the number of commits since the previous
annotated tag. Something like <tag_name>-<#commits>-g<commit_hash>,
e.g., v3.5.0-56-1234567.

Iñaki

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Duncan Murdoch-2
On 25/12/2017 7:00 AM, Iñaki Úcar wrote:

> 2017-12-25 12:30 GMT+01:00 Duncan Murdoch <[hidden email]>:
>> The one negative aspect of Winston's effort is caused by this weakness. If
>> you tell me that something happened in revision 73909, I know it was recent.
>> If you tell me that something appeared in commit 2e80059, it wastes my time
>> looking up that commit and putting it in context.
>
> The output from "git describe" is something similar to an svn
> revision: it describes the number of commits since the previous
> annotated tag. Something like <tag_name>-<#commits>-g<commit_hash>,
> e.g., v3.5.0-56-1234567.

But we're not using git, we're just sending emails back and forth.  I
don't need to run svn to get some useful information from the number
73909.  Winston's web page at
https://github.com/wch/r-source/commit/2e80059 does display the number
73909 if you know where to look, but his email doesn't contain it.

I don't know about other svn users, but I'd be perfectly content to read
something like "This appears to have been added in rev 73909 (diff shown
here: https://github.com/wch/r-source/commit/2e80059)."

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Juan Telleria
Maybe I'm new, and forgive my ignorance, but maybe in the future (~ X years
from now) the R Project could be managed entirely from github, by doing
pull requests and only R Core having commit rights...

Would make the forking process also easier... And could be a good roadmap.

But we're not using git, we're just sending emails back and forth.  I don't

> need to run svn to get some useful information from the number 73909.
> Winston's web page at https://github.com/wch/r-source/commit/2e80059 does
> display the number 73909 if you know where to look, but his email doesn't
> contain it.
>
> I don't know about other svn users, but I'd be perfectly content to read
> something like "This appears to have been added in rev 73909 (diff shown
> here: https://github.com/wch/r-source/commit/2e80059)."
>
> Duncan Murdoch

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Suzen, Mehmet-2
On 26 December 2017 at 00:00, Juan Telleria <[hidden email]> wrote:
> Maybe I'm new, and forgive my ignorance, but maybe in the future (~ X years
> from now) the R Project could be managed entirely from github, by doing

I strongly disagree. Are you aware that github is a commercial
company, github inc. [1] ?
What about gitlab? or Microsoft's codeplex? There are other services
similar to github, why github?
What happens if github goes out of business?

R-project should be maintained in the academic network and under
auspices of universities.


 [*]  GitHub, Inc.
       https://en.wikipedia.org/wiki/GitHub

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Juan Telleria
Mmmmm... I see... thank you Suzen.

Juan


> I strongly disagree. Are you aware that github is a commercial
> company, github inc. [1] ?
> What about gitlab? or Microsoft's codeplex? There are other services
> similar to github, why github?
> What happens if github goes out of business?
>
> R-project should be maintained in the academic network and under
> auspices of universities.
>
>
>  [*]  GitHub, Inc.
>        https://en.wikipedia.org/wiki/GitHub
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Juan Telleria
However, and hope not to be off-topic, a git repository (github, gitlab,
codeplex, etc., not just solely github) could constitute a tidy approach,
and make things easier to R Core :)

By putting the focus on version control, the line of changes made with each
commit (With the possibility to reverse changes), and not verbose e-mails.

Juan

I strongly disagree. Are you aware that github is a commercial

>> company, github inc. [1] ?
>> What about gitlab? or Microsoft's codeplex? There are other services
>> similar to github, why github?
>> What happens if github goes out of business?
>>
>> R-project should be maintained in the academic network and under
>> auspices of universities.
>>
>>
>>  [*]  GitHub, Inc.
>>        https://en.wikipedia.org/wiki/GitHub
>>
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Uwe Ligges-3


On 26.12.2017 00:45, Juan Telleria wrote:
> However, and hope not to be off-topic, a git repository (github, gitlab,
> codeplex, etc., not just solely github) could constitute a tidy approach,
> and make things easier to R Core :)
>
> By putting the focus on version control, the line of changes made with each
> commit (With the possibility to reverse changes), and not verbose e-mails.

That works well with svn, and we have the sequential labels which are
e.g. important for bisecting changes.
I do not see how I can find this out with git easily.

Best,
Uwe Ligges



> Juan
>
> I strongly disagree. Are you aware that github is a commercial
>>> company, github inc. [1] ?
>>> What about gitlab? or Microsoft's codeplex? There are other services
>>> similar to github, why github?
>>> What happens if github goes out of business?
>>>
>>> R-project should be maintained in the academic network and under
>>> auspices of universities.
>>>
>>>
>>>   [*]  GitHub, Inc.
>>>         https://en.wikipedia.org/wiki/GitHub
>>>
>>
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Duncan Murdoch-2
On 03/01/2018 6:11 PM, Uwe Ligges wrote:

>
>
> On 26.12.2017 00:45, Juan Telleria wrote:
>> However, and hope not to be off-topic, a git repository (github, gitlab,
>> codeplex, etc., not just solely github) could constitute a tidy approach,
>> and make things easier to R Core :)
>>
>> By putting the focus on version control, the line of changes made with each
>> commit (With the possibility to reverse changes), and not verbose e-mails.
>
> That works well with svn, and we have the sequential labels which are
> e.g. important for bisecting changes.
> I do not see how I can find this out with git easily.

I think git supports bisection, but I don't see how switching to git
would make anything easier for R Core.  Perhaps Juan can tell us which R
Core tasks would be easier in git.

Duncan Murdoch

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: R CMD check warning about compiler warning flags

Juan Telleria
I repeat it for all the reason I gave to Duncan on a personal E-mail, It is
a lot of text, and I might be wrong, but I attach it in case it is useful:

A) I feel Version Control (SVN) is great when there is a little group of
people maintaining the code (RCore ~ 20); but Git could allow a bigger
group of people (for example ~200) working simultaneously on perfect and
polish the code without overlapping each other, and RCore (~20) check that
code, and do commits.

This would allow an even more robust base language foundation, or
improvements such as writing some base code more efficiently in C++, etc.

I will put a SQL Transactions simile for further explain this issue:
* SVN is like a Table-Lock.
* And GIT is a Row-Lock in the Table.

Table-Lock works well with very few connections, and as there are only few
connections, users are happy with it.

But it prevents other client connections to query that table at the same
time, and does not allow high concurrency.

B) I feel that Version Control is a little bit obscure for people who are
not from R-Core Mailing List, as:
* We cannot see what gets updated with each R-devel specific version.
* And have communication tools flexible enough to suggest a little patch
(changes in a few lines of code all scattered over R Code) by ourselves
other than E-mails. ¿What if our fixes are very sparse?

Communication and Patches for Collaboration are difficult and tedious for
Non-Core Contributors.

C) Reverting a whole version can cause that bugs that where already fixed,
to be reverted (I've seen it once in R).

D) Making a whole new version for a single change in 1 line of code is
inefficient, and time consuming. In GitHub it would take few seconds.

E) Google Trends indicates that GIT is getting more and more used than SVN
by other developments. If it works for others, why should not work for R?

F) It would also be important to know what the opinion of key R
contributors outside R-Core is, for example:

* Hadley Wickham.
* Other important R Package Authors.

If they would feel more willing to help on R Core Language Development with
GitHub, Gitlab, etc.

Juan

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel