[Rd] Rtools and R 4.0.0?

[Jeroen Ooms]

On Mon, Apr 6, 2020 at 9:39 AM Gabriel Becker <gabembecker using gmail.com> wrote:
>
> Hi Kevin,
>
> On Wed, Apr 1, 2020 at 9:36 PM Kevin Ushey <kevinushey using 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.