Hi all, I received some questions this week about rtools4 (the windows compiler bundle) in particular regarding support for ucrt, so below a brief summary of the status quo:
As of May 2021, rtools4 has full support for ucrt. The toolchain configuration is based on the upstream msys2 configuration, which are very stable, and widely used by other open source projects as well as the mingw-w64 developers themselves. The latest builds of rtools4 now contain 3 toolchains: - c:\rtools40\mingw32: the 32-bit gcc-8-3.0 toolchain used as of R 4.0.0 - c:\rtools40\mingw64: the 64-bit gcc-8-3.0 toolchain used as of R 4.0.0 - c:\rtools40\ucrt64: a new 64-bit gcc-10.3.0 toolchain targeting ucrt The total install size is about 1gb. Hence, if R were to switch to ucrt at some point, users and sysadmins that have installed rtools4 after May 2021 are already equipped with proper toolchains for building packages for both R 4.0+ as well as a potential ucrt versions of R. As before, for each of these toolchains, all extra libraries needed by CRAN packages can easily be installed in rtools4 through pacman [1]. All system libraries in rtools-packages [2] have ucrt64 binaries [3]. When users contribute an update or a new rtools package, the CI automatically builds and checks binaries for each of the above toolchains, e.g [4]. The process is 100% automatic, transparent, and reproducible. This provides a degree of accountability, and makes it easy for R package authors to suggest improvements for the C/C++ libraries that they depend on (many have done so in the past 2 years). Rtools4 is preinstalled on major CI/cloud services such as GitHub actions. Popular open-source projects such as Apache-Arrow and TileDB are already using the rtools4 toolchains to automatically build and test their C++ libraries, as well as R bindings, for each commit, on all target architectures (including ucrt64). Any R package author can use the the same free services to check their packages on all compile targets using rtools4 toolchains [5]. The r-devel CI tool on https://r-devel.github.io checks every commit to base-R using ucrt64 toolchain from rtools4, which has proven to be very stable. I am also aware that Tomas Kalibera also provides alternative "experimental ucrt toolchain": a 6gb tarball with manually built things on his personal machine. It is unclear to me why it was decided to take this approach; it is certainly not needed to support ucrt (ucrt is literally one flag in the toolchain configuration). Fortunately, the ucrt tooclchains from rtools4 and Tomas Kalibera use the same version of mingw-w64 and gcc, and are fully compatible, so package authors could still use the rtools4 ucrt compilers icw the R-devel-ucrt version that was built using this experimental toolchain [5]. We spent an enormous amount of effort in the past years standardising the Windows build tooling, and making the infrastructure automated, open and accessible, such that everyone can learn how this works and get involved. Many people have. Today if you install R and Rtools4 on Windows, things "just work", regardless of whether this is a student laptop, university server, or online CI system. Anyone can build R packages, base-R, or any of the system libraries, following the steps, and using standard tooling that other open source projects use. I think it would be a big step back of R-core decides to go back to a black-box system that is so opaque and complex that only one person knows how it works, and would make it much more difficult for students, universities, and other organisations to build R packages and libraries on Windows. Jeroen [1] https://github.com/r-windows/docs/blob/master/rtools40.md#readme [2] https://github.com/r-windows/rtools-packages [3] https://cran.r-project.org/bin/windows/Rtools/4.0/ [4] https://github.com/r-windows/rtools-packages/pull/221 [5] https://github.com/r-windows/docs/blob/master/ucrt.md ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel