Syntax: Build R-Interface with Rtools45 static toolchain

[FBartos]

Why

The Windows R-Interface build was using the MSYS2 UCRT64 dynamic compiler path (C:/rtools45/ucrt64/bin/gcc.exe). That produced R-Interface DLLs with runtime imports such as libgcc_s_seh-1.dll, libstdc++-6.dll, and libwinpthread-1.dll.

That is the wrong contract for installed Windows binaries: CRAN documents that Rtools is not required for installing binary packages, and Rtools45 provides the static toolchain under C:/rtools45/x86_64-w64-mingw32.static.posix for this use case.

The Windows workflow also assumed Visual Studio 2022 paths while running on windows-latest. On the current GitHub image, windows-latest resolved to a VS 2026 image, so configure failed before tests because the expected VS 2022 CRT merge module path did not exist.

What changed

• Pin the Windows workflow to windows-2022, matching the existing VS 2022 path assumptions and Qt win64_msvc2022_64 package.
• Split Rtools discovery into:
  • RTOOLS_PATH for the existing UCRT64 package/library assets.
  • RTOOLS_STATIC_TOOLCHAIN_PATH for the official Rtools45 static compiler toolchain.
  • RTOOLS_BUILD_TOOLS_PATH for MSYS build tools such as make.exe.
• Build the nested R-Interface project with:
  • C:/rtools45/x86_64-w64-mingw32.static.posix/bin/gcc.exe
  • C:/rtools45/x86_64-w64-mingw32.static.posix/bin/g++.exe
  • C:/rtools45/usr/bin/make.exe
  • Unix Makefiles
• Add a Windows CI check that fails if either R-Interface DLL imports libgcc, libstdc++, or libwinpthread.
• Fix Windows Qt deployment to use the windeployqt executable from the configured Qt prefix instead of whichever Qt install appears first on PATH.
• Make the generated Windows deploy script respect the install-time prefix, so local installs such as cmake --install build --prefix ... deploy into the requested staging folder.
• Replace two Boost.Iostreams null-stream uses with a tiny standard-library null stream. This avoids linking Boost.Iostreams only to discard logging output and fixed a local MSVC/Boost link failure.

Verification

Local Windows verification on Rtools45 and Qt 6.10.2 MSVC:

• Configured with Ninja, MSVC, C:/Qt/6.10.2/msvc2022_64, and C:/rtools45/ucrt64.
• Confirmed CMake selected:
  • C:/rtools45/x86_64-w64-mingw32.static.posix as the R-Interface compiler toolchain.
  • C:/rtools45/usr/bin/make.exe as the R-Interface make program.
  • C:/Qt/6.10.2/msvc2022_64/bin/windeployqt.exe for deployment.
• cmake --build build --target all succeeds.
• objdump -p on both libR-Interface.dll and libR-InterfaceNoRInside.dll shows no imports matching libgcc, libstdc++, or libwinpthread.
• dyn.load() succeeds for both R-Interface DLLs from the bundled R.
• Local staged install contains Qt6WebEngineQuick.dll, Qt6WebEngineCore.dll, and QtWebEngineProcess.exe, resolving the missing Qt6WebEngineQuick.dll issue when running the installed copy.

CI failures addressed:

• Windows configure failure: Microsoft_VC143_CRT_x64.msm cannot be found because windows-latest had moved to a VS 2026 runner while the workflow passed VS 2022 paths. This PR now pins the job to windows-2022.
• Ubuntu build failure from the unrelated TOML parser change has been removed; the TOML parser is back to the development-branch implementation.

References:

• https://cran.r-project.org/bin/windows/Rtools/rtools45/rtools.html
• https://cran.r-project.org/bin/windows/base/howto-R-4.5.html

[vandenman]

This nullOutputStream looks like a the second/ third answer of https://stackoverflow.com/questions/8243743/is-there-a-null-stdostream-implementation-in-c-or-libraries

It's kinda nice because it drops a boost dependency I guess but not really mandatory for this PR.

@JorisGoosen any thoughts on this?

[vandenman]

also, if this works we should check if we can simplify the build guide because people on Windows won't need to do anything special anymore beyond installing Rtools.

[vandenman]

For reference, this came up here: https://github.com/jasp-stats/jaspSyntax/actions/runs/28031244975/job/82972218848?pr=9

We install custom stuff via Rtools on windows, see

jasp-desktop/Docs/development/jasp-build-guide-windows.md

Line 69 in 3415d2e

pacman -Syu mingw-w64-ucrt-x86_64-toolchain mingw-w64-ucrt-x86_64-boost jsoncpp bison flex make autoconf automake git wget cmake mingw-w64-ucrt-x86_64-libiconv libiconv-devel libtool zlib-devel zlib mingw-w64-ucrt-x86_64-zlib mingw-w64-ucrt-x86_64-jsoncpp

Those were not statically linked along, and an agent told me that wasn't possible either. We could ship additional Rtools dlls on windows only, but making this unnecessary seemed like a more appropriate solution.

[vandenman]

@FBartos For your AI:

This step on windows CI

      - name: dependencies for rtools
        run: |
             C:\rtools45\msys2_shell.cmd -defterm -here -no-start -ucrt64 -lc "pacman -S --noconfirm mingw-w64-ucrt-x86_64-toolchain make autoconf automake wget git cmake mingw-w64-ucrt-x86_64-libiconv libtool zlib-devel mingw-w64-ucrt-x86_64-zlib mingw-w64-ucrt-x86_64-jsoncpp mingw-w64-ucrt-x86_64-boost mingw-w64-ucrt-x86_64-readstat"

still installs those custom Rtools libraries that are exactly the ones that we're trying to avoid. So we're not actually sure whether the current PR fixes this! Please remove that step, check if CI passes, and fix any errors that may appear.

[FBartos]

This should now address the Rtools concern.

The broad Windows dependencies for rtools step has been removed. The PR now has an isolated Windows check R-Interface static toolchain on Windows job that does not install the custom UCRT libraries from the old step, builds R-Interface, and checks the produced DLL imports for unexpected MinGW runtime dependencies such as libgcc, libstdc++, and libwinpthread.

I also updated the Windows build guide to reflect the split:

• syntax-only / R-Interface builds only need a normal Rtools45 install;
• full Desktop builds still need ReadStat/librdata for importer support, documented as a narrower source-build setup matching CI rather than the old broad package install.

Checks are green on head c5066e95e: Ubuntu build-jasp, Windows check R-Interface static toolchain on Windows, and Windows build test on Windows.

[FBartos]

@vandenman I think this should now fully cover your concern about the Windows CI still installing the Rtools/UCRT libraries we were trying to prove unnecessary.

What changed:

• removed the old broad dependencies for rtools install step;
• added an isolated Windows check R-Interface static toolchain on Windows job that builds R-Interface without installing those custom UCRT libraries;
• added an import check on the resulting R-Interface DLLs for unexpected MinGW runtime dependencies such as libgcc, libstdc++, and libwinpthread;
• kept the full Windows Desktop build green using only the narrower source-build setup needed for ReadStat/librdata importer support;
• updated the Windows build guide so syntax-only / R-Interface builds are documented as requiring only a normal Rtools45 install, with the ReadStat/librdata setup separated as full Desktop importer setup.

The current head is c5066e95e, and the relevant checks are green: Ubuntu build-jasp, Windows check R-Interface static toolchain on Windows, and Windows build test on Windows.