これで，PowerShellからcl.exeを使うためにゴニョゴニョしなくて済む，と思ったら，コンパイラが32bit環境になっていました．
次のコマンドで確認したときに，パスがHostx86のx86になっていました．
(gcm cl).Sourceどうしても64bit環境が使いたいのですが，コマンドプロンプトについては，x86，x86からx64のクロスコンパイル，x64，x64からx86のクロスコンパイル，としっかり組み合わせが用意されているのに，PowerShellについては用意されていません．
そこで，Developer PowerShell for VS 2019のリンクのプロパティを見て，実際に何をやっているのか確認してみました．
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -noe -c "&{Import-Module """C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\Microsoft.VisualStudio.DevShell.dll""";Enter-VsDevShell インスタンスID}"インスタンスIDの部分は，たぶん環境によって変わります．
どうやら，Enter-VsDevShellというものを呼び出しているようです．取り合えずヘルプを見てみましょう．
Get-Help -Detailed Enter-VsDevShell非常に簡単なことしか書いていませんが，-DevCmdArgumentsというものがあることに気付きます．これに -help を渡してみます．
Enter-VsDevShell インスタンスID -DevCmdArguments -helpすると，どうやらvsdevcmd.batを裏で呼んでいるようです．これについても情報が少ないのですが，あれこれ調べた結果，-arch=x64を指定してやれば良さそうです．
Developer PowerShell for VS 2019のリンクのプロパティからリンク先を書き換えてみましょう．
%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe -noe -c "&{Import-Module """C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\Microsoft.VisualStudio.DevShell.dll""";Enter-VsDevShell インスタンスID -DevCmdArguments -arch=x64}"書き換えたら，そのリンクからPowerShellを起動します．そして，もう一度次のコマンドを実行します．
(gcm cl).Source無事，Hostx64のx64が選択されています．
やってやりました！
ちなみにインスタンスIDは，書いてあるものを使えば良いのですが，間違えて消してしまったりした場合，vswhereというものを使えば見れるようです．
注意点として，どうもリンク先の長さに上限があるらしく，書き換え方次第では入りきらなくなるようです．
0 件のコメント:
コメントを投稿