Support VS2017

[KindDragon]

This patch ae5e63a doesn't work with VS2017RC1

See also Finding the location of a VC++2017 install

BTW toolset should be vc141 for VS2017 and %VSxxxCOMNTOOLS% environment variable doesn't exist

[KindDragon]

How execute command powershell -v 3 -exec bypass .\return-msvc-path.ps1 15 in jam file (msvc.jam) and get their output and exitcode?

[KindDragon]

Script: KindDragon/build@c03c11c#diff-edcbda45192bb7d102a378db2cabd8f3

[MarcelRaad]

%VSxxxCOMNTOOLS% environment variable doesn't exist

%VS150COMNTOOLS% does exist if you use one of the Visual Studio command prompts.

[KindDragon]

Yes, but for previous versions VS this was not required. Not convenient to run the VS command prompts before Boost.Build

[AndrewPardoe]

There are three solutions to this problem:

1. Store a small executable in your repo. Run that executable to locate VS installs. You can identify the latest VS install, and ascertain that it contains MSVC (as opposed to a C#-only install.) We can help you create the optimal (as in, smallest size and specific operation) executable.

2. Use a PowerShell module. This offers the same capability as option 1, but requires that you install a PS module on the user's machine. Worse, I think that the install is interactive (though non-admin.) On Win10 it's straightforward, on earlier versions it's more difficult to install PS modules. More details here: https://blogs.msdn.microsoft.com/heaths/2017/01/25/visual-studio-setup-powershell-module-available/, invoking the command as so: Get-VSSetupInstance | Select-VSSetupInstance -Latest -Require Microsoft.VisualStudio.Component.VC.Tools.x86.x64

3. Brute force it through a command script. The following command script searches every single-lettered drive (whether or not it exists) for a file called vcvars64.bat. It calls every vcvars64 it finds. It then checks to make sure it can find a cl.exe. It's unholy and I'm ashamed to have written it but it may suit your purposes:

for %%i in (a b c d e f g h i j k l m n o p q r s t u v w x y z) do for /F "tokens=*" %%j in ('dir /s /b %%i:\vcvars64.bat') do call "%%j" 
call where cl.exe && (echo success) || (echo cl.exe not found)

Edit: Here's a version suggested by a colleague that will call the first vcvars64.bat and exit.

for %%i in (a b c d e f g h i j k l m n o p q r s t u v w x y z) do for /F "tokens=*" %%j in ('dir /s /b %%i:\vcvars64.bat') do (
    call "%%j"
    call where cl.exe && goto :EOF 
)

Note that you can change the 64 to a 32 or even call vcvarsall.bat.

[KayEss]

I'm so pleased I'm not at the pointy end of making a decision about how to do this :(

Shouldn't there be some mechanism for finding the default compiler that the platform provides? After all this must come up for every single eco system that also relies on native code extensions: node, python, ruby etc.

[AndrewPardoe]

There should be. And I'm trying to get a better solution introduced. What seems to be ideal to me is that we'd ship a binary (similar to option 1 above) that prints the path and sets an environment variable for the last-installed version of VS that contains the MSVC workload. I can't guarantee success but I can guarantee I'll try to help y'all get through this.

[teeks99]

Store a small executable in your repo. Run that executable to locate VS installs.

How does it do this under the hood? Does it do a full search of every drive path? I doubt it. I've read that there isn't a single registry key to query, but are there multiple that we could use to throw together a search path?

[AndrewPardoe]

Oh, goodness no. It calls a COM API that lists all VS installs. Once you've got an install instance you can query for which workloads are installed, which is the most recent install, etc.

The main code repo is here: https://github.com/microsoft/vs-setup-samples

I hacked up a simplified, command-line compilable version here: https://gist.github.com/AndrewPardoe/975a821aa3e865cfaf576fafbfdcbe2f

That said, we'd want to write a custom version that suited your scenario.

[teeks99]

And how does the service behind that COM interface know/determine where the installs are? It can't be turtles all the way down.

If there isn't a better solution than 1-3, I propose that we basically leave things as-is for the build.bat side. By supporting the three default paths we will hit 99% of the users. Then for the remaining 1% that don't use the default install path, and we don't detect, on windows we can output a message saying "we weren't able to detect a compiler, if you have VS 2017 installed to a non-default path, you must set the %VS15COOMNTOOLS% variable before calling build.bat/bootstrap.bat".

Once we find any compiler to build the b2 tool, we can have the tool actually query the COM API to figure out the full installed versions and set the appropriate variables. Not being a b2 expert, I don't know if this is possible, I believe it is all done in jam scripts now...is there a avenue to get something like this inside the binary? Would that be normal operating procedure or a terrible hack?

P.S. Forcing users to query a COM API does not help skeptical users buy in to the concept that Microsoft is getting better about supporting industry standards.