Add win-arm64 support using cl.exe #9
Conversation
recipe/build.sh
Outdated
| # An executable with mingw and `static-libgcc` is 42K | ||
| # An executable with vcruntime statically linked (-MT) in is 920K | ||
| # An executable with vcruntime dynamically linked (-MD) in is 84K | ||
| # For arm64, since we don't have mingw, we are going to use -MD | ||
| # to reduce the binary size. Let's hope that all arm64 machines | ||
| # have vcruntime140.dll installed. |
There was a problem hiding this comment.
Hmm, we don't need to run standalone. So let's use MD
There was a problem hiding this comment.
We do need them to run from Scripts which doesn't have a vcruntime140.dll.
There was a problem hiding this comment.
So do we need -MD or -MT? I think we are currently using MD but your last message hints at needing MT as far as I can see? 🤔
There was a problem hiding this comment.
I would use -MT for safety for launchers - it's too likely to end up running from a place where it can't find a suitable runtime.
Using -MD matter more for Python itself, because extension modules will also need to load it, and they'll want to share state. The launcher (I assume) is only going to create a new process, rather than dynamically loading DLLs, so it won't be a huge impact.
| run: | ||
| # Any Python works as `%PREFIX%/python.exe` is present | ||
| # cli-64.exe (and friends) will look for it as `../python.exe`, so that's | ||
| # why we package the executables in `%PREFIX%/Scripts` | ||
| - python | ||
| - python # [x86_64] |
There was a problem hiding this comment.
We are only selecting this so the solver doesn't error out right now, right? But in the future we should re-enable it?
|
<3 This is awesome, just have a couple comments but otherwise LGTM. |
|
Thanks! |
Description