Hello, Has a decision been made yet as to whether R 4.0.0 on Windows is going to be built using the new gcc8 toolchain (described at https://cran.r-project.org/bin/windows/testing/rtools40.html)?>From the sidelines, I can see that the toolchain is being used tobuild and test packages on CRAN; if there are any remaining issues that I can help to try and run down (either in R or any CRAN packages) I'd be happy to try and help. FWIW, I'm excited at the prospect at seeing a new toolchain for Windows, since it would imply support for C++17 and so it would become easier for CRAN packages to depend on the newer C++ standard. Thanks, Kevin
Also related to this, I tried looking in the archives and couldn't find a previous discussion, was gcc 8.1 chosen over gcc 9 because mingw-w64 does not support v9 yet? It looks like 9 is the first version that makes C++17 support non-experimental https://gcc.gnu.org/gcc-9/changes.html Regards, Steve Bronder Website: stevebronder.com Phone: 412-719-1282 Email: sbronder at stevebronder.com On Thu, Apr 2, 2020 at 12:36 AM Kevin Ushey <kevinushey at gmail.com> wrote:> Hello, > > Has a decision been made yet as to whether R 4.0.0 on Windows is going > to be built using the new gcc8 toolchain (described at > https://cran.r-project.org/bin/windows/testing/rtools40.html)? > > From the sidelines, I can see that the toolchain is being used to > build and test packages on CRAN; if there are any remaining issues > that I can help to try and run down (either in R or any CRAN packages) > I'd be happy to try and help. > > FWIW, I'm excited at the prospect at seeing a new toolchain for > Windows, since it would imply support for C++17 and so it would become > easier for CRAN packages to depend on the newer C++ standard. > > Thanks, > Kevin > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
On 02/04/2020 05:35, Kevin Ushey wrote:> Hello, > > Has a decision been made yet as to whether R 4.0.0 on Windows is going > to be built using the new gcc8 toolchain (described at > https://cran.r-project.org/bin/windows/testing/rtools40.html)?Short answer: 'no'.>>From the sidelines, I can see that the toolchain is being used to > build and test packages on CRAN; if there are any remaining issues > that I can help to try and run down (either in R or any CRAN packages) > I'd be happy to try and help.It is still under consideration, but resource constraints are biting hard as people's lives get more complicated. -- Brian D. Ripley, ripley at stats.ox.ac.uk Emeritus Professor of Applied Statistics, University of Oxford
Hi Kevin, On Wed, Apr 1, 2020 at 9:36 PM Kevin Ushey <kevinushey at gmail.com> wrote:> Hello, > > FWIW, I'm excited at the prospect at seeing a new toolchain for > Windows, since it would imply support for C++17 and so it would become > easier for CRAN packages to depend on the newer C++ standard. >One thing to keep in mind (having been the R installation owner in such a place for multiple years) is that many coproprate or otherwise controlled compute environments may not have access to a c++17 compiler on their servers so making it easy for packages to rely on that is not purely beneficial to all parts of the R community. Not saying that should heavily inform this decision, just wanted to throw that out there since the topic came up. Personally if R packages are making the switch all the way up to 17 this soon I have to say i'm glad I got out of the R administration game. I don't have anything to add about the toolchain update discussions , though from what Prof Ripley said I guess they are ongoing. ~G> > Thanks, > Kevin > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
On Mon, Apr 6, 2020 at 9:15 AM Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:> > On 02/04/2020 05:35, Kevin Ushey wrote: > > Hello, > > > > Has a decision been made yet as to whether R 4.0.0 on Windows is going > > to be built using the new gcc8 toolchain (described at > > https://cran.r-project.org/bin/windows/testing/rtools40.html)? > > Short answer: 'no'. > > >>From the sidelines, I can see that the toolchain is being used to > > build and test packages on CRAN; if there are any remaining issues > > that I can help to try and run down (either in R or any CRAN packages) > > I'd be happy to try and help. > > It is still under consideration, but resource constraints are biting > hard as people's lives get more complicated.Given the amount of work that has gone into this and the importance of an up-to-date toolchain for maintaining well-functioning and current system libraries and R packages, I think it should be considered to delay the R 4.0 release over this until everyone is ready.
On Mon, Apr 6, 2020 at 9:39 AM Gabriel Becker <gabembecker at gmail.com> wrote:> > Hi Kevin, > > On Wed, Apr 1, 2020 at 9:36 PM Kevin Ushey <kevinushey at gmail.com> wrote: > > > Hello, > > > > FWIW, I'm excited at the prospect at seeing a new toolchain for > > Windows, since it would imply support for C++17 and so it would become > > easier for CRAN packages to depend on the newer C++ standard. > > > > One thing to keep in mind (having been the R installation owner in such a > place for multiple years) is that many coproprate or otherwise controlled > compute environments may not have access to a c++17 compiler on their > servers so making it easy for packages to rely on that is not purely > beneficial to all parts of the R community.No, you're missing an important point here. On Windows, the toolchain version is tied to the version of R and we try to keep supporting at least one or two previous versions of R. So this means we always need to support the legacy toolchain for a while as well. Hence if we switch Windows to gcc-8 for R 4.0, we still rely on gcc-4.9 for continued support of R 3.3-3.6. This lag is what is making the maintenance of windows system libraries painful, and why we need to plan ahead. This is different from Linux where version of the compiler is given by the OS and not tied to the version of R. If we would miss the boat again, and R 4.0 on Windows would stick with gcc-49, this means we need to keep supporting gcc-49 as long as we want to support R-4.0, which is at least 2022 or 2023. This would be pretty bad. Even currently the latest versions of important system libraries used by R packages (e.g. the gdal stack) require recent compilers and cannot be built anymore with gcc-49. As more C++ projects are adopting C++14/17, we can no longer update these system libraries, missing out on all upstream fixes and advances. This would seriously decrement the quality of the R ecosystem.