Repository navigation
Fix windows build and add basic actions - #9
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
…ntain permissions' Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
On the windows-latest VS 2026 image the hard-coded vcvarsall.bat does not exist; cmd printed "The system cannot find the path specified." and carried on, so CMake fell back to the Rtools GCC on PATH and the build only failed much later, inside Conan's MSVC build of bzip2. Keep the vcvarsall path in one place, stop the job when it is missing or fails, and configure jasp-desktop with cl explicitly: Rtools' ucrt64/bin is now on GITHUB_PATH, so GCC sits right next to MSVC for every later step. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
boutinb
left a comment
boutinb
left a comment
There was a problem hiding this comment.
This fixes the failing Build SyntaxInterface Libraries run on master (run 36749182024), so I think it should go in.
Why master fails: windows-latest is now the windows-2025-vs2026 image, where the hard-coded VS 2022 vcvarsall.bat doesn't exist. Each cmd step printed "The system cannot find the path specified." and carried on without an MSVC environment. CMake then quietly took GCC from PATH: static Qt was built with MinGW GCC 15.2, and jasp-desktop was configured with the Rtools static toolchain's gcc and cmake.exe. It finally broke in Conan's MSVC build of bzip2, because that cmake handed the link step's manifest to windres. Pinning windows-2022 fixes it, and it also changes the Qt cache key, so the MinGW-built Qt that run saved isn't reused.
What I pushed (e55171c):
- The
vcvarsall.batpath is now defined once (VCVARSALL), and every Windows step stops with a clear error if it's missing or fails, instead of producing a misleading failure much later. - jasp-desktop is configured with
-DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl. This PR putsC:\rtools45\ucrt64\binonGITHUB_PATH, so GCC sits right next to MSVC in every later step; naming the compiler means it can't silently fall back to GCC again.
What this doesn't fix yet: the published v0.97.1 libR-InterfaceNoRInside-windows-x86_64.dll still imports libgcc_s_seh-1.dll and libstdc++-6.dll. That goes away with jasp-stats/jasp-desktop#6269 (R-Interface built with the Rtools static toolchain). Once that's merged and a release is built from it, the "Install Rtools45 ucrt64 compiler" step and the GITHUB_PATH line here can go, and the DLL import check from #6269 could be added to this workflow.
Other remarks:
- The license change from
GPL (>= 2)toGPL-3 + file LICENSEmatches the GPL-3LICENSEthat's been there since the first commit, but it's a license change, so worth an explicit OK. Also,+ file LICENSEis meant for additional terms; with the full GPL text in that file, CRAN's checks complain. PlainLicense: GPL-3is the usual form. configure.winwrites temp files to/tmp/jaspsyntax-*.$$.RUNTIME_DIRS_FILE,PROCESSED_FILEandMISSING_DLLS_FILEare never removed, including on the error exits.mktemp -dplus atrapthat cleans up on exit would fix that.install.libs.Rnow globssymbols.rds, but nothing produces that file.rcmdcheck.ymlusesactions/checkout@v2(the other workflow uses@v6) and has no newline at the end of the file.
Checked and fine: the bash → POSIX sh conversion of configure, configure.win and tools/check-syntaxinterface-symbols.sh passes sh -n and dash -n with no bashisms left. Every native symbol src/syntaxfunctions.cpp uses is declared in the v0.97.1 source bundle's header, so the default tag bump is consistent. The R CMD check workflow against the published binaries is a nice addition.
3 participants
The action will install the package with the latest static build, which help identify situations when only some OSes fail to build.