Skip to content

Update Windows RTools support and add Windows ARM64 - #864

Open
ndabas wants to merge 6 commits into
stan-dev:developfrom
ndabas:develop
Open

ndabas wants to merge 6 commits into
stan-dev:developfrom
ndabas:develop

Conversation

@ndabas

@ndabas ndabas commented Sep 18, 2026

Copy link
Copy Markdown

Submission Checklist

  • Run unit tests
  • Declare copyright holder and open-source license: see below

Summary

I have updated the RTools installation support on Windows, so versions up to 4.5 are now supported. Critically, that now adds native support for Windows on ARM64. I have updated the rest of the build-related code to work on both AMD64 and ARM64 versions of Windows.

The one thing worth pointing out is that I ran into 4 tests failing only on Windows ARM; this is because those particular tests were running an exe and immediately trying to delete it. On Windows 11 ARM, Windows Defender cannot be disabled, per the readme; and Windows Defender tries to scan every executable when it is run, so deleting it immediately fails.

We can choose to not add Windows ARM to the main workflow, as that workflow has a subset of supported platforms anyway. In that case I can remove the changes to main.yml and the delete-retry workaround, let me know.

I also added lots of tests and a new workflow to test the toolchain installation on Windows.

Copyright and Licensing

Please list the copyright holder for the work you are submitting (this will be you or your assignee, such as a university or company):

Nikhil Dabas

By submitting this pull request, the copyright holder is agreeing to license the submitted work under the following licenses:

@WardBrian WardBrian left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ndabas! This looks very nice overall.

My main concerns are about the overlap this has with the large refactor currently happening in #851. I think that together they will actually clean up a lot of the code, but it will likely require some changes here once that one is merged.

on:
workflow_dispatch:
schedule:
# weekly: catches CRAN retiring the pinned installer revisions

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My recollection is this is part of why we've stuck with rtools40 for so long, because there is not a stable link for the newer ones. Is that what this comment means?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes that is what this comment was about. However I noticed that in the CmdStan docs, they point to stable download URLs from the R-Hub project (like https://github.com/r-hub/rtools45/releases/download/latest/rtools45.exe) so I incorporated those in the code. Let me know if that sounds fine -- and I will remove this comment and the weekly run.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That does sound better to me

EXTENSION = '.exe' if platform.system() == 'Windows' else ''


def delete_file(path: str, timeout: float = 5.0) -> None:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this function could be in the test utilities, rather than the actual package

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, I'll move it over.

Comment thread cmdstanpy/compilation.py
Comment on lines +202 to +203
# clang treats backslashes in the -include path as escapes
self._user_header = Path(self._user_header).absolute().as_posix()

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might make sense to improve the path handling for this in cmdstan itself:
https://github.com/stan-dev/cmdstan/blob/d3d5df6a22565edbe13edbd4eb40762cc8c5a4d6/make/program#L47

For other variables we use subst to swap backslashes:
https://github.com/stan-dev/cmdstan/blob/d3d5df6a22565edbe13edbd4eb40762cc8c5a4d6/make/program#L83

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the pointers, I'll see how to clean this up a bit.

Comment on lines +78 to +79
# Windows ARM64 needs the Stan Math support added in stan-dev/math#3051
MIN_WINDOWS_ARM64_VERSION = (2, 35)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is happening in parallel to #851, which will be defining a minimum cmdstan version greater than this for support anyway, so I'm not sure we need to check this specifically here

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay that sounds great -- I'll remove this check then.

print(
"""Arguments:
-v (--version) :CmdStan version
-v (--version) : RTools version: 3.5, 4.0, 4.4 or 4.5

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we will be releasing version 2.0 soon, we can definitely remove the old 3.5 support, if not also 4.0

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably harmless to leave the old ones around, but yes, we can eliminate some test burden by at least getting rid of 3.5. I'll do that.

Comment on lines +40 to +42
# CRAN embeds build revisions in the RTools 4.2+ installer filenames, so we
# use the r-hub mirror, which publishes them under a stable 'latest' tag.
# These are the builds the CmdStan guide points users at.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to go against the comment in the ci workflow about the links changing

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes indeed, when I was checking the CmdStan docs I discovered that they have these stable links. I'll remove the CI comment as mentioned.

Comment thread docsrc/installation.rst
ARM64 build of RTools 4.4 or 4.5, which CmdStanPy installs and detects
automatically. CmdStan 2.35 or later is required.

A Python interpreter built for Intel/AMD and running under emulation reports an

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering about emulation, since we don't provide windows/aarch64 builds for the stanc3 compiler -- but I guess it works out?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes since it's just a compiler of sorts it works fine on ARM64 under emulation. I can look at that as well after this PR to get native support.

EXTENSION,
RTOOLS_LAYOUTS,
RToolsLayout,
cmdstan_path,

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It doesn't look like all these new imports are actually used outside of the other utilities, so probably don't need to appear here

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll verify that and remove these if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants