Windows GHA workflow #175
Windows GHA workflow #175
Conversation
| let source = format!("{}/src/modules", env!("CARGO_MANIFEST_DIR")); | ||
| root = Path::new(&source).to_path_buf(); | ||
| let source = env!("CARGO_MANIFEST_DIR"); | ||
| root = Path::new(&source).join("src").join("modules").to_path_buf(); |
There was a problem hiding this comment.
Fixed a bug that only showed up in release builds. Need \ on Windows!
| - name: Setup R | ||
| uses: r-lib/actions/setup-r@v2 | ||
| with: | ||
| r-version: '4.3.2' |
There was a problem hiding this comment.
I think we are going to eventually have to decide what our minimum supported R version is, and then build libR-sys against that.
Then for any C utilities that comes from a newer version of R than that, we would dynamically load those out of the user's R.dll at runtime using dlopen or the Windows equivalent. RStudio seems to take this approach in a few places (For example, with R_DefParamsEx(), introduced in R 4.0.0 ish but R really wants you to use that now on startup)
If libR-sys doesn't support that version of R that we pin against, we may have to maintain our own bindings 😢
But otherwise what currently happens is that on Windows we probably can't load up R 4.0.0 or earlier right now due to us using some utilities that came from R versions after that (even if we guard against using those with a runtime R version check, that isn't enough, because the linker needs to resolve the symbols at runtime and it can't)
DavisVaughan
force-pushed
the
feature/windows-github-workflow
branch
from
595fda1
to
02a58f4
Compare
| # We try to dynamically look up the year (2022) and exact version (14.37.32822) | ||
| # in case they change on us | ||
| # A number of the pieces are unstable (year, Community vs Enterprise, exact version) | ||
| # so we try and use `vswhere.exe` and `vsdevcmd.bat` to find the exact path |
There was a problem hiding this comment.
I think you can mostly ignore the specifics of the changes in this file. I thought I had it right before, but that was with a Community version of the vs tools, and the Enterprise version is on the runner.
Anyways, I think it should be more robust now through the use of the "official" vswhere utility
Since they aren't on the same worker
DavisVaughan
force-pushed
the
feature/windows-github-workflow
branch
from
bc39086
to
73390ef
Compare
General idea is:
build_macosto build the Macarkbinaries (arm64 and intel)build_windowsto build the Windowsark.exe(only x64 for now, likely arm in the future?)create_releasebundles themodules/into the Mac and Windows specific zip filesWe get artifacts on the tags like:
ark-0.1.31-windows-x64.zipark-0.1.31-debug-windows-x64.zipI've left in the
x64here to go along with theuniversalofdarwin-universalin our Mac builds. I assume in the future if we need ARM windows builds then we will either have a universal build that replaces this, or an additional-arm64artifact