search

microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
94.88k stars 8.22k forks source link

Terminal doesn't detect developer command prompt on ARM64 #12903

Open Alovchin91 opened 2 years ago

Alovchin91 commented 2 years ago

Windows Terminal version

1.12.10733.0

Windows build number

10.0.22000.613

Other Software

Visual C++ Build Tools 2022 17.1.4

Steps to reproduce

Expected Behavior

There are profiles for Developer Command Prompt and Developer PowerShell for VS2022 in Terminal.

Actual Behavior

There are no such profiles.

Alovchin91 commented 2 years ago

Probably related to this but it's been marked as Fixed for the second time already so there's no reason not to trust them, right? 🙃

zadjii-msft commented 2 years ago

What coincidence, we were just talking about this on a mail thread. I think internally this is https://task.ms/dd/1522793.

zadjii-msft commented 2 years ago

This might be fixed in 17.3 Preview 2. I'm not super familiar with how VS tracks work, so it's hard for me to tell, and I won't be able to definitively confirm without ARM64 hardware.

I'm moving this out of 1.15 to 1.16 for now, since that's probably about when that'll be fixed.

shuffle2 commented 2 years ago

I just installed VS 17.3 Preview 5.0 on arm64 device (surface pro x) and noticed that the "Developer Command Prompt" Terminal profile(s) do get created, however they specify -host_arch=x64 in their configured command lines (the target arch is correctly set to arm64, tho). This causes cl.exe when run from such a Terminal to be emulated x64 processes which is not ideal for speed reasons. Not sure if it's same as this issue or should have another one opened for it...

zadjii-msft commented 2 years ago

Hmm. @shuffle2 When you open up the Start menu, is there a link to the ARM developer command prompt & powershell instances? In here: image

We probably need to update our own generator to pull in the ARM profiles on ARM, but I think they're supposed to be there now, after 17.3 preview 2.

zadjii-msft commented 2 years ago

Oh I mean, this would totally do it too: https://github.com/microsoft/terminal/blob/5c35a64bb3e4d158ee8c56024c5ca2412999742a/src/cascadia/TerminalSettingsModel/VsDevCmdGenerator.cpp#L39-L46

I wonder if there's a clean way for us to pass in -host_arch=arm64, and have it stealth fall back to amd64 on versions of VS before there was an ARM toolchain. @heaths thoughts?

heaths commented 2 years ago

That's making a big assumption that it's supported by that version of VS. At the very least you'd need a version check, though I don't know on what version. We should talk with someone in VC since it seems even their dev prompt shortcuts haven't been updated accordingly. There may be good reason.

shuffle2 commented 2 years ago

Hmm. @shuffle2 When you open up the Start menu, is there a link to the ARM developer command prompt & powershell instances?

yup: image

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2022\Visual Studio Tools>tree /f
Folder PATH listing for volume Local Disk
Volume serial number is 00000259 8843:F9C0
C:.
│   Debuggable Package Manager Preview.lnk
│   Debuggable Package Manager.lnk
│   Developer Command Prompt for VS 2022 Preview.lnk
│   Developer PowerShell for VS 2022 Preview.lnk
│
└───VC
        ARM64 Native Tools Command Prompt for VS 2022 Preview.lnk
        ARM64_x64 Cross Tools Command Prompt for VS 2022 Preview.lnk
        ARM64_x86 Cross Tools Command Prompt for VS 2022 Preview.lnk
        x64 Native Tools Command Prompt for VS 2022 Preview.lnk
        x64_x86 Cross Tools Command Prompt for VS 2022 Preview.lnk
        x86 Native Tools Command Prompt for VS 2022 Preview.lnk
        x86_x64 Cross Tools Command Prompt for VS 2022 Preview.lnk
DHowett commented 2 years ago

That's making a big assumption that it's supported by that version of VS. At the very least you'd need a version check, though I don't know on what version. We should talk with someone in VC since it seems even their dev prompt shortcuts haven't been updated accordingly. There may be good reason.

This is probably a bit aggressive, but... 17.3 preview builds have ARM64 native tool developer prompts already; if we just put a stake in the ground, call it ">=17.3", and bear the risk of a little wrongness if it turns out that ARM64 is pushed back to 17.4 or further... how bad would that be?

What I imagine the worst case scenario to be: we mess up the seven people (guess; not informed by data) who have installed the entire amd64 VS on arm64 and simultaneously use it with Terminal.

DHowett commented 2 years ago

Immediately afterwards

Well, 17.3 is now public and doesn't have the ARM64 bits. Time to eat my hat. :smile:

shuffle2 commented 2 years ago

Fwiw: https://devblogs.microsoft.com/visualstudio/visual-studio-2022-17-3-is-now-available/

Version 17.4 will be the first version of Visual Studio generally available as a native Arm64 application.

heaths commented 2 years ago

Immediately afterwards

Well, 17.3 is now public and doesn't have the ARM64 bits. Time to eat my hat. 😄

I wonder if it's worth querying that the arm64 components are installed, which can be done similar to what I did here in vswhere: https://github.com/microsoft/vswhere/blob/dac187ab5f3a5f28ab59f5c069aeaf3c3a51aa30/src/vswhere.lib/InstanceSelector.cpp#L249-L299

I'd be happy to submit a PR for this (wouldn't even need a version check then), but it was my (mis?)understanding from the internal thread that we really didn't need to detect the host. Or was that just orthogonal?

Alovchin91 commented 2 years ago

I believe this is a bit more complicated.

One can install C++ Build Tools for ARM64 from an x64 package. In fact, that's what I've been doing for Rust development for ages. However, that doesn't mean that ARM64 native toolchain is available — it only appeared in 17.2.

But there's more. Even though ARM64 native toolchain (by that I mean the HostARM64 folder) is present in 17.2 and works, the VCVARS BAT is broken in 17.2. So going with 17.4 is probably the safest bet. (Yet to check with 17.3)

heaths commented 2 years ago

A version check alone isn't enough, though. The component may not be installed. The APIs support querying for the exact component(s), though there is some risk - though small - of the teams changing component IDs in future versions.

Alovchin91 commented 2 years ago

there is some risk - though small - of the teams changing component IDs in future versions.

I would deem it highly unlikely as that would break waaay too much 3rd party code.

heaths commented 2 years ago

I was the architect on the VS Setup engine. It's happened. That's why we documented that customers should ideally only depend on workload IDs, which shouldn't change unless deprecated (removed, specifically), for example. But, the VC team has been pretty good about keeping component IDs unchanged exactly for this reason.