Jeroen,
Sorry, I was unclear. I'm not arguing against switching tot the new windows
tool chain. Without being involved or knowing the details of any
remaining difficulties, I am de facto for that.
I was specifically responding to the prospect of R packages moving to
directly rely on c++17 this quickly, which Kevin brought up. R itself
obviously won't be relying on c++17 since there is no c++ code in it at all
I believe.
Best,
~G
On Mon, Apr 6, 2020 at 5:38 AM Jeroen Ooms <jer...@berkeley.edu> wrote:
> On Mon, Apr 6, 2020 at 9:39 AM Gabriel Becker <gabembec...@gmail.com>
> wrote:
> >
> > Hi Kevin,
> >
> > On Wed, Apr 1, 2020 at 9:36 PM Kevin Ushey <kevinus...@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.
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
