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
