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.

[teeks99]

There's also the registry key:
HKLM\Software\Classes\.cpp\OpenWithProgids

This should contain a key for all the programs that are setup to open CPP files, Visual Studio registers itself as one of these: VisualStudio.cpp.53c3cca0

Going to that location in the registry:
HKLM\Software\Classes\[VisualStudio.cpp.53c3cca0]

Allows you to find:
HKLM\Software\Classes\[VisualStudio.cpp.53c3cca0]\shell\Open\Command Default with the value: "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenev.exe" /dde

Presumably with some nice batch file trimming, this path could be traversed in build.bat. I still need to test with multiple versions and see what that turns into, presumably they'll all be there, and we can just pick the first one that has a 2017 in it...or maybe not if they're installed into separate dirs.

[KindDragon]

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.

VS only for Windows. COM API is industry standard for Windows

[KindDragon]

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.

We can also distribute PowerShell module with Boost.Build, and use script like my KindDragon/build@c03c11c#diff-edcbda45192bb7d102a378db2cabd8f3

[eldiener]

I do not think you want to distribute PowerShell with Boost Build, any more than you want to distribute Python, or some C++ compiler with Boost Build.

[AndrewPardoe]

PowerShell is included in Windows 7 and up. It's essentially a different command shell with more scripting ability. Please, all, remember we are only talking about Windows here.

@KindDragon, if you opt to use a PowerShell module it does pretty much everything for you with regards to detecting the installed VS builds and their workloads. You shouldn't need any more detection logic.

[refack]

I have written a few scripts that use only builtin windows tools to find the path for VS2017 installation and VsDevCmd.bat's location

[AndrewPardoe]

FWIW, Heath Stewart has made another sample available on how to locate VS: https://blogs.msdn.microsoft.com/heaths/2017/02/25/vswhere-available/

[KindDragon]

Cool! Now, if someone suggested how to call it from Boost Jam file would have been nice 😄

[teeks99]

It doesn't sound like this utility will ship with visual studio, so I'm not sure how it will really help us. I don't think the community will be very excited about packaging it with the source distribution and I don't think we should download it during the script execution.

It still sounds to me like the best idea is to make our own PowerShell script that does the same basic function as that program. I'm not 100% sure that is possible though, most of the examples I've seen have still depended on another binary.

[AndrewPardoe]

This tool does not ship with Visual Studio currently. I've asked that the team consider deploying it with the VC++ workload but there's nothing to report on that front yet.

You own your own build system: maybe the logic can be incorporated in that binary? I'm thinking of something similar to what @ras0219-msft did with VCPkg.

[teeks99]

Yeah, the logic could definitely be incorporated in the binary...the real issue is how to do the bootstrapping to build the binary. That is just a .bat file, it just needs to find any working compiler so that it can build the tool.

[KindDragon]

We can just push exe file to the repository or download it from github when bootstrapping Boost.Build.

[KayEss]

That opens a can of worms. Who would be responsible for the integrity of the file? Who would sign it? How would it work when the next compiler is released?

What are the implications to the user experience of converting the BAT file to a powershell script? Who does it leave needing to download and install extra things?

[refack]

@juandent I think you'll at least need all the .jam files

[juandent]

Ok, thanks … I will check that Juan From: Refael Ackermann [mailto:notifications@github.com] Sent: Friday, March 17, 2017 4:57 PM To: boostorg/build <build@noreply.github.com> Cc: juandent <juandent@mac.com>; Mention <mention@noreply.github.com> Subject: Re: [boostorg/build] Support VS2017 (#157) @juandent <https://github.com/juandent> I think you'll at least need all the .jam files — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#157 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AFHnFdC1msQ4-V0iljrVNK6ZBR96dVGDks5rmw-jgaJpZM4LyHmS> . <https://github.com/notifications/beacon/AFHnFUx7DqCVZqM4SNI0BdiQSvraNUcRks5rmw-jgaJpZM4LyHmS.gif>

[KindDragon]

Clone boost from github (https://github.com/boostorg/boost/tree/develop) develop branch and try build from it

[juandent]

Hi @KindDragon I downloaded as you suggested but got this:

C:\Users\Juan Dent\Documents\GitHub\boost-develop>bootstrap.bat
Building Boost.Build engine
The system cannot find the path specified.
Access is denied.

Failed to build Boost.Build engine.
Please consult bootstrap.log for further diagnostics.

You can try to obtain a prebuilt binary from

   http://sf.net/project/showfiles.php?group_id=7586&package_id=72941

Also, you can file an issue at http://svn.boost.org
Please attach bootstrap.log in that case.

Should I copy the develop branch on top of Boost_1_63_0?

Or should I copy the boost-build instead on top of Boost_1_63_0?

Regards,
Juan Dent

[KindDragon]

bootstrap.bat should work, attach bootstrap.log here

[teeks99]

For those still following this thread, please voice your opinion on the mailing list:
http://lists.boost.org/Archives/boost/2017/03/233543.php

[refack]

For those still following this thread, please voice your opinion on the mailing list:
http://lists.boost.org/Archives/boost/2017/03/233543.php
I'm not on the list but

👍 for 14.10 & vc1410

[KindDragon]

For those still following this thread, please voice your opinion on the mailing list:
http://lists.boost.org/Archives/boost/2017/03/233543.php

I'm for option two vc$(PlatformToolsetVersion), but I'm fine with option one too

[teeks99]

@refack and @KindDragon could you guys please go and indicate your preference on the mailing list. As this is a multi-project spanning decision we need to form the consensus there.

[refack]

We need some MS feedback
/cc @AndrewPardoe @heaths

[KindDragon]

@refack and @KindDragon could you guys please go and indicate your preference on the mailing list. As this is a multi-project spanning decision we need to form the consensus there.

I wasn't subscribed to mailing list

[heaths]

@refack regarding what, exactly? Is this a deployment issue? From the thread you referenced, it looks more like a VC-related build/reference issue. I can't really help with that more than to direct you at them. If so, I can see if I can find one of them on GitHub and CC them on this thread.

[AndrewPardoe]

@heaths, this is entirely on me & the MSVC team. I'll pick up the discussion on the Boost mailing list.

[refack]

@AndrewPardoe @heaths thank you both!

[refack]

@grafikrobot I'm interested to know what was the reason for the regression by 838c622? Since it's surely not a recursion issue.
If it's a protest against Microsoft I'm all for it!

[heaths]

vswhere is now available as part of the install starting today with Visual Studio 15.2 preview 2: https://blogs.msdn.microsoft.com/heaths/2017/04/21/vswhere-is-now-installed-with-visual-studio-2017/

[DISAPPEARED13]

It seems that boost 1.82 support VS2017 MSVC14.1, but I cannot run Boost.Build with Error C1083 cannot open include file stdint.h, or run it in powershell showing the error C1043, it's quite wired because I can include this file in the IDE, and no error occurs. How to solve this problem? Could you give me some advice!!?? please!

[DISAPPEARED13]

plus, the toolset is MSVC14.10 like 14.12 / 14.16, it seems that still run with TOOLSET vc141, is it correct? but I cannot run vc142 and vc143, i guess it should be vc141. the TOOLSET should be right.