[VS2017][release] vswhere.exe

newer
[gsoc2017] Please review my code...

older
program options - adding new...

Mateusz Loskot

28 Mar 2017 28 Mar '17

1:41 p.m.

Hi, This is regarding issues with locating VS 2017 toolset(s).

...

From CMake ml, I learned about vswhere utility being developed by Microsoft

https://github.com/Microsoft/vswhere vswhere.exe (390 KB) is downloadable from https://github.com/Microsoft/vswhere/releases I'm not sure how exactly, but perhaps it would solve some of the Boost.Build's headache (eg. particular PowerShell version required). For example, it can find all VS versions I've got installed (10.0, 11.0, 12.0, 14.0, 15.0): vswhere.exe -legacy find a particular version: vswhere -legacy -version [11.0,12.0) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Show replies by date

Rene Rivera

28 Mar 28 Mar

2:34 p.m.

On Tue, Mar 28, 2017 at 8:41 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...

Hi,

This is regarding issues with locating VS 2017 toolset(s). From CMake ml, I learned about vswhere utility being developed by Microsoft

https://github.com/Microsoft/vswhere

vswhere.exe (390 KB) is downloadable from

https://github.com/Microsoft/vswhere/releases

I'm not sure how exactly, but perhaps it would solve some of the Boost.Build's headache (eg. particular PowerShell version required).

For example, it can

find all VS versions I've got installed (10.0, 11.0, 12.0, 14.0, 15.0):

vswhere.exe -legacy

find a particular version:

vswhere -legacy -version [11.0,12.0)

Yes, we are ware of that utility. As we advocated (or rather more like pestered) MS to write it. Unfortunately it didn't make it into the release itself. And at least because of license issues I'm not comfortable including it in the Boost tree, or install. Once Microsoft includes it as part of a VS release and installs it so that it is accessible in the PATH we will use it. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Mateusz Loskot

6:18 p.m.

On 28 March 2017 at 16:34, Rene Rivera via Boost wrote:

...

On Tue, Mar 28, 2017 at 8:41 AM, Mateusz Loskot via Boost wrote:

...
This is regarding issues with locating VS 2017 toolset(s). From CMake ml, I learned about vswhere utility being developed by Microsoft

https://github.com/Microsoft/vswhere

vswhere.exe (390 KB) is downloadable from

https://github.com/Microsoft/vswhere/releases

Yes, we are ware of that utility. As we advocated (or rather more like pestered) MS to write it.

I see. I couldn't fish anything about from the list archives.

...

Unfortunately it didn't make it into the release itself. And at least because of license issues I'm not comfortable including it in the Boost tree, or install. Once Microsoft includes it as part of a VS release and installs it so that it is accessible in the PATH we will use it.

Makes sense. Thanks, -- Mateusz Loskot, http://mateusz.loskot.net

degski

29 Mar 29 Mar

1:43 p.m.

On 28 March 2017 at 08:34, Rene Rivera via Boost wrote:

...

And at least because of license issues I'm not comfortable including it in the Boost tree, or install.

Why don't you simply ask them, whether it is OK to include vswhere.exe in the boost distribution? This way you can also ensure that it works with the boost code as "you" are the one controlling the version of vswhere.exe to be included. degski

Beman Dawes

2:34 p.m.

On Wed, Mar 29, 2017 at 9:43 AM, degski via Boost wrote:

...

On 28 March 2017 at 08:34, Rene Rivera via Boost wrote:

...
And at least because of license issues I'm not comfortable including it in the Boost tree, or install.

Why don't you simply ask them, whether it is OK to include vswhere.exe in the boost distribution? This way you can also ensure that it works with the boost code as "you" are the one controlling the version of vswhere.exe to be included.

IANAL, but the https://github.com/Microsoft/vswhere readme is very clear: "*vswhere* is designed to be a redistributable, single-file executable that can be used in build or deployment scripts to find where Visual Studio - or other products in the Visual Studio family - is located."

"redistributable" is the term Microsoft uses elsewhere to describe files they hold copyright to that are OK for users to redistribute." There really doesn't seem to me to be any need to check with them, but just to be sure I'll check with Andrew Pardoe. --Beman

Rene Rivera

2:57 p.m.

On Wed, Mar 29, 2017 at 9:34 AM, Beman Dawes via Boost < boost@lists.boost.org> wrote:

...

On Wed, Mar 29, 2017 at 9:43 AM, degski via Boost wrote:

...
On 28 March 2017 at 08:34, Rene Rivera via Boost wrote:

...
And at least because of license issues I'm not comfortable including it in the Boost tree, or install.

Why don't you simply ask them, whether it is OK to include vswhere.exe in the boost distribution? This way you can also ensure that it works with the boost code as "you" are the one controlling the version of vswhere.exe to be included.

IANAL, but the https://github.com/Microsoft/vswhere readme is very clear: "*vswhere* is designed to be a redistributable, single-file executable that can be used in build or deployment scripts to find where Visual Studio - or other products in the Visual Studio family - is located."

"redistributable" is the term Microsoft uses elsewhere to describe files they hold copyright to that are OK for users to redistribute." There really doesn't seem to me to be any need to check with them, but just to be sure I'll check with Andrew Pardoe.

The key license issue is that they are using the MIT license. It requires attribution and license terms with *any* redistribution. Which could cause problems for people and companies that download Boost and further redistribute their products. As it's unclear if they should include that attribution and license in their products as derivatives because they use Boost as a product. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

degski

3:23 p.m.

On 29 March 2017 at 08:57, Rene Rivera via Boost wrote:

...

It requires attribution and license terms with *any* redistribution.

Klaim - Joël Lamotte

30 Mar 30 Mar

2:05 p.m.

On 29 March 2017 at 17:23, degski via Boost wrote:

...

On 29 March 2017 at 08:57, Rene Rivera via Boost wrote:

...
It requires attribution and license terms with *any* redistribution.

C:\Users\User>vswhere Visual Studio Locator, version 1.0.58 Copyright (C) Microsoft Corporation. All rights reserved.

The attribution is built-in AFAICS.

Note however that it should be used only once VS2017 is installed: C:\Users\me>vswhere 'vswhere' is not recognized as an internal or external command, operable program or batch file. This is because I don't have VS2017 installed yet on this computer, but I have VS2013 and VS2015. Some kind of conditional is necssary about the availability of vswhere.

...

degski

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

Mateusz Loskot

2:56 p.m.

On 30 March 2017 at 16:05, Klaim - Joël Lamotte via Boost wrote:

...

On 29 March 2017 at 17:23, degski via Boost wrote:

...
On 29 March 2017 at 08:57, Rene Rivera via Boost wrote:

...
It requires attribution and license terms with *any* redistribution.

C:\Users\User>vswhere Visual Studio Locator, version 1.0.58 Copyright (C) Microsoft Corporation. All rights reserved.

The attribution is built-in AFAICS.

Note however that it should be used only once VS2017 is installed:

C:\Users\me>vswhere 'vswhere' is not recognized as an internal or external command, operable program or batch file.

The utility is not deployed by any VS installer. You need to download it separately, from GitHub. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Klaim - Joël Lamotte

3 p.m.

On 30 March 2017 at 16:56, Mateusz Loskot via Boost wrote:

...

On 30 March 2017 at 16:05, Klaim - Joël Lamotte via Boost wrote:

...
On 29 March 2017 at 17:23, degski via Boost wrote:

...
On 29 March 2017 at 08:57, Rene Rivera via Boost
...
wrote:

...
It requires attribution and license terms with *any* redistribution.

C:\Users\User>vswhere Visual Studio Locator, version 1.0.58 Copyright (C) Microsoft Corporation. All rights reserved.

The attribution is built-in AFAICS.

Note however that it should be used only once VS2017 is installed:

C:\Users\me>vswhere 'vswhere' is not recognized as an internal or external command, operable program or batch file.

The utility is not deployed by any VS installer. You need to download it separately, from GitHub.

Oh ok I thought it was part of the recent update.

...

Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

Glen Fernandes

3:20 p.m.

Mateusz wrote:

...

The utility is not deployed by any VS installer. You need to download it separately, from GitHub.

I hope that does not mean the Boost release itself would have to contain a Windows executable for the purpose of finding VS. Maybe by the next release the problem that would need solving isn't "How to find VS on a user's machine" but instead "How to find vswhere.exe on a user's machine". I wonder if the suggested solution[1] to that problem would also involve iterating through drive letters A through Z... Glen [1] http://lists.boost.org/Archives/boost/2017/02/232843.php -- View this message in context: http://boost.2283326.n4.nabble.com/VS2017-release-vswhere-exe-tp4693141p4693... Sent from the Boost - Dev mailing list archive at Nabble.com.

Rene Rivera

3:46 p.m.

On Thu, Mar 30, 2017 at 10:20 AM, Glen Fernandes via Boost < boost@lists.boost.org> wrote:

...

Mateusz wrote:

...
The utility is not deployed by any VS installer. You need to download it separately, from GitHub.

I hope that does not mean the Boost release itself would have to contain a Windows executable for the purpose of finding VS.

That is the general recommendation from Microsoft.

...

Maybe by the next release the problem that would need solving isn't "How to find VS on a user's machine" but instead "How to find vswhere.exe on a user's machine".

I wonder if the suggested solution[1] to that problem would also involve iterating through drive letters A through Z...

Haha.. Indeed.. I would only hope that they install it someplace in the PATH. But given the track record so far on this I guess that's a vain hope. One of the suggestions to Microsoft I made is that they should install it as an OS update https://github.com/Microsoft/vswhere/issues/41. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Andrey Semashev

4:44 p.m.

On 03/30/17 18:46, Rene Rivera via Boost wrote:

...

On Thu, Mar 30, 2017 at 10:20 AM, Glen Fernandes via Boost < boost@lists.boost.org> wrote:

...
Mateusz wrote:

...
The utility is not deployed by any VS installer. You need to download it separately, from GitHub.

I hope that does not mean the Boost release itself would have to contain a Windows executable for the purpose of finding VS.

That is the general recommendation from Microsoft.

IMO, requiring a BLOB executable in a source distribution is unacceptable (regardless of the license of the BLOB). This compromises distribution transparency and may affect its review and certification, if one is performed by Boost users. This also raises a security issue since the executable may be compromised and contain malware. I consider vswhere a part of the toolchain. We do not distribute toolchains in our releases, and we should not make an exception for MSVC. If MS cannot supply this tool in VS installers or as an OS update, and we still want to use it, make it a precondition for the users to install first and add a link to the Getting Started page. But please, don't put BLOBs into the source distributions.

Steve M. Robbins

31 Mar 31 Mar

5:04 p.m.

On Thu, Mar 30, 2017 at 07:44:30PM +0300, Andrey Semashev via Boost wrote:

...

I consider vswhere a part of the toolchain. We do not distribute toolchains in our releases, and we should not make an exception for MSVC. If MS cannot supply this tool in VS installers or as an OS update, and we still want to use it, make it a precondition for the users to install first and add a link to the Getting Started page. But please, don't put BLOBs into the source distributions.

Seconded! Agree completely. Note that downstream distributions, like Debian linux, will often "re-package" the source distribution to remove such files, so it adds a little bit of effort to the distributors. -Steve

Paul A. Bristow

4 Apr 4 Apr

8:59 a.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev via Boost Sent: 30 March 2017 17:45 To: boost@lists.boost.org Cc: Andrey Semashev Subject: Re: [boost] [VS2017][release] vswhere.exe

On 03/30/17 18:46, Rene Rivera via Boost wrote:

...
On Thu, Mar 30, 2017 at 10:20 AM, Glen Fernandes via Boost < boost@lists.boost.org> wrote:

...
Mateusz wrote:

...
The utility is not deployed by any VS installer. You need to download it separately, from GitHub.

I hope that does not mean the Boost release itself would have to contain a Windows executable for the purpose of finding VS.

That is the general recommendation from Microsoft.

IMO, requiring a BLOB executable in a source distribution is unacceptable (regardless of the license of the BLOB). This compromises distribution transparency and may affect its review and certification, if one is performed by Boost users. This also raises a security issue since the executable may be compromised and contain malware.

I consider vswhere a part of the toolchain. We do not distribute toolchains in our releases, and we should not make an exception for MSVC. If MS cannot supply this tool in VS installers or as an OS update, and we still want to use it, make it a precondition for the users to install first and add a link to the Getting Started page. But please, don't put BLOBs into the source distributions.

+1 (Perhaps install process can assume that, if needed, vswhere.exe exists and in PATH. But if not found then produce an error message telling the user where and how to install it in order to proceed). Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Mateusz Loskot

9:09 a.m.

On 4 April 2017 at 10:59, Paul A. Bristow via Boost wrote:

...

...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev via Boost Sent: 30 March 2017 17:45 To: boost@lists.boost.org Cc: Andrey Semashev Subject: Re: [boost] [VS2017][release] vswhere.exe

On 03/30/17 18:46, Rene Rivera via Boost wrote:

...
On Thu, Mar 30, 2017 at 10:20 AM, Glen Fernandes via Boost < boost@lists.boost.org> wrote:

...
Mateusz wrote:

...
The utility is not deployed by any VS installer. You need to download it separately, from GitHub.

I hope that does not mean the Boost release itself would have to contain a Windows executable for the purpose of finding VS.

That is the general recommendation from Microsoft.

IMO, requiring a BLOB executable in a source distribution is unacceptable (regardless of the license of the BLOB). This compromises distribution transparency and may affect its review and certification, if one is performed by Boost users. This also raises a security issue since the executable may be compromised and contain malware.

I consider vswhere a part of the toolchain. We do not distribute toolchains in our releases, and we should not make an exception for MSVC. If MS cannot supply this tool in VS installers or as an OS update, and we still want to use it, make it a precondition for the users to install first and add a link to the Getting Started page. But please, don't put BLOBs into the source distributions.

+1

(Perhaps install process can assume that, if needed, vswhere.exe exists and in PATH.

But if not found then produce an error message telling the user where and how to install it in order to proceed).

+1 Andrey's idea is very good Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Rene Rivera

2:34 p.m.

On Tue, Apr 4, 2017 at 4:09 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...

On 4 April 2017 at 10:59, Paul A. Bristow via Boost wrote:

...
...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev via Boost Sent: 30 March 2017 17:45 To: boost@lists.boost.org Cc: Andrey Semashev Subject: Re: [boost] [VS2017][release] vswhere.exe

On 03/30/17 18:46, Rene Rivera via Boost wrote:

...
On Thu, Mar 30, 2017 at 10:20 AM, Glen Fernandes via Boost < boost@lists.boost.org> wrote:

...
Mateusz wrote:

...
The utility is not deployed by any VS installer. You need to download it separately, from GitHub.

I hope that does not mean the Boost release itself would have to contain a Windows executable for the purpose of finding VS.

That is the general recommendation from Microsoft.

IMO, requiring a BLOB executable in a source distribution is unacceptable (regardless of the license of the BLOB). This compromises distribution transparency and may affect its review and certification, if one is performed by Boost users. This also raises a security issue since the executable may be compromised and contain malware.

I consider vswhere a part of the toolchain. We do not distribute toolchains in our releases, and we should not make an exception for MSVC. If MS cannot supply this tool in VS installers or as an OS update, and we still want to use it, make it a precondition for the users to install first and add a link to the Getting Started page. But please, don't put BLOBs into the source distributions.

+1

(Perhaps install process can assume that, if needed, vswhere.exe exists and in PATH.

But if not found then produce an error message telling the user where and how to install it in order to proceed).

+1 Andrey's idea is very good

Given the choices: * Brittle BAT+Powershell+C# detection script dance. * Including vswhere in distribution. * Requiring vswhere preinstall (either by user or OS or VS2017). I'd also prefer for the last one. And it's essentially what I'm been pushing Microsoft to do for weeks now. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Rene Rivera

9:13 p.m.

On Tue, Apr 4, 2017 at 9:34 AM, Rene Rivera wrote:

...

On Tue, Apr 4, 2017 at 4:09 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...
On 4 April 2017 at 10:59, Paul A. Bristow via Boost wrote:

...
...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev via Boost Sent: 30 March 2017 17:45 To: boost@lists.boost.org Cc: Andrey Semashev Subject: Re: [boost] [VS2017][release] vswhere.exe

On 03/30/17 18:46, Rene Rivera via Boost wrote:

...
On Thu, Mar 30, 2017 at 10:20 AM, Glen Fernandes via Boost < boost@lists.boost.org> wrote:

...
Mateusz wrote: > The utility is not deployed by any VS installer. > You need to download it separately, from GitHub.

I hope that does not mean the Boost release itself would have to contain a Windows executable for the purpose of finding VS.

That is the general recommendation from Microsoft.

IMO, requiring a BLOB executable in a source distribution is unacceptable (regardless of the license of the BLOB). This compromises distribution transparency and may affect its review and certification, if one is performed by Boost users. This also raises a security issue since the executable may be compromised and contain malware.

I consider vswhere a part of the toolchain. We do not distribute toolchains in our releases, and we should not make an exception for MSVC. If MS cannot supply this tool in VS installers or as an OS update, and we still want to use it, make it a precondition for the users to install first and add a link to the Getting Started page. But please, don't put BLOBs into the source distributions.

+1

(Perhaps install process can assume that, if needed, vswhere.exe exists and in PATH.

But if not found then produce an error message telling the user where and how to install it in order to proceed).

+1 Andrey's idea is very good

Given the choices:

* Brittle BAT+Powershell+C# detection script dance. * Including vswhere in distribution. * Requiring vswhere preinstall (either by user or OS or VS2017).

I'd also prefer for the last one. And it's essentially what I'm been pushing Microsoft to do for weeks now.

Scratch that.. I've now tried to make build changes to use the vswhere tool. And it's useless. It has too many bugs. It tells you nothing about specific msvc installs (ie cl.exe). It only tells you about the overall VS2017 install. As far as I can tell, when one install multiple cl.exe-s (as will be possible in some mythical future according to Microsoft) it will not tell you about them individually. You still have to put it the logic for guessing the individual versions by navigating the filesystem. And if we are going to ask users to install this thing it's not worth it. My recommendation... We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS. That way we can use the existing logic we have for that. And the user doesn't have to install mystery executables. When Microsoft fixes this mess we can support their fix. Thoughts? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Marcel Raad

9:50 p.m.

Boost - Dev mailing list wrote

...

My recommendation...

We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS. [...]

Thoughts?

+1, that's how I've always built Boost. Marcel -- View this message in context: http://boost.2283326.n4.nabble.com/VS2017-release-vswhere-exe-tp4693141p4693... Sent from the Boost - Dev mailing list archive at Nabble.com.

Mateusz Loskot

10:06 p.m.

On 4 April 2017 at 23:50, Marcel Raad via Boost wrote:

...

Boost - Dev mailing list wrote

...
My recommendation...

We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS. [...]

Thoughts?

+1, that's how I've always built Boost.

+1 likewise Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Andrey Semashev

10:13 p.m.

On Wed, Apr 5, 2017 at 12:13 AM, Rene Rivera via Boost wrote:

...

We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS. That way we can use the existing logic we have for that. And the user doesn't have to install mystery executables. When Microsoft fixes this mess we can support their fix.

Thoughts?

Works for me. Is this only needed for bootstrap.bat? Is Boost.Build still able to create the .cmd helper scripts with environment setup so that users don't have to run b2 from the VS command line prompt (after the scripts have been created, naturally)?

Peter Dimov

10:20 p.m.

Rene Rivera wrote:

...

My recommendation...

We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS.

Does this mean that we'll revert the existing detection logic? If so (it worked for me), can we not at least check the default install locations, if VS150COMNTOOLS isn't set?

Rene Rivera

11:02 p.m.

On Tue, Apr 4, 2017 at 5:20 PM, Peter Dimov via Boost

...

wrote:

...

Rene Rivera wrote:

My recommendation...

...
We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS.

Does this mean that we'll revert the existing detection logic?

Only the logic dealing with the PowerShell helper scripts. If so (it worked for me), can we not at least check the default install

...

locations, if VS150COMNTOOLS isn't set?

There was already logic for common paths when building b2, aka bootstrap part. I'll be adding equivalent logic in msvc.jam. WHich, funnily, we already have some of as msvc 7.1 needed it. In other words, Microsoft has managed to regress to the state of 7.1 as far as the install is concerned. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

degski

10:33 p.m.

On 4 April 2017 at 15:13, Rene Rivera via Boost wrote:

...

On Tue, Apr 4, 2017 at 9:34 AM, Rene Rivera wrote: We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS.

Voila, finally some sense... but "Run the build from an *elevated* VS command prompt." degski

Rene Rivera

10:59 p.m.

On Tue, Apr 4, 2017 at 5:33 PM, degski via Boost wrote:

...

On 4 April 2017 at 15:13, Rene Rivera via Boost wrote:

...
On Tue, Apr 4, 2017 at 9:34 AM, Rene Rivera wrote: We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS.

Voila, finally some sense... but "Run the build from an *elevated* VS command prompt."

Why? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Tom Kent

5 Apr 5 Apr

11:29 a.m.

On Tue, Apr 4, 2017 at 4:13 PM, Rene Rivera via Boost

...

wrote:

...

On Tue, Apr 4, 2017 at 9:34 AM, Rene Rivera wrote:

...
On Tue, Apr 4, 2017 at 4:09 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...
On 4 April 2017 at 10:59, Paul A. Bristow via Boost wrote:

...
...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev via Boost Sent: 30 March 2017 17:45 To: boost@lists.boost.org Cc: Andrey Semashev Subject: Re: [boost] [VS2017][release] vswhere.exe

On 03/30/17 18:46, Rene Rivera via Boost wrote:

...
On Thu, Mar 30, 2017 at 10:20 AM, Glen Fernandes via Boost < boost@lists.boost.org> wrote:

> Mateusz wrote: >> The utility is not deployed by any VS installer. >> You need to download it separately, from GitHub. > > I hope that does not mean the Boost release itself would have to contain a > Windows executable for the purpose of finding VS.

That is the general recommendation from Microsoft.

IMO, requiring a BLOB executable in a source distribution is unacceptable (regardless of the license of the BLOB). This

compromises

...
...
...
...
distribution transparency and may affect its review and certification, if one is performed by Boost users. This also raises a security issue since the executable may be compromised and contain malware.

I consider vswhere a part of the toolchain. We do not distribute toolchains in our releases, and we should not make an exception for MSVC. If MS cannot supply this tool in VS installers or as an OS update, and we still want to use it, make it a precondition for the users to install first and add a link to the Getting Started page. But please, don't put BLOBs into the source distributions.

+1

(Perhaps install process can assume that, if needed, vswhere.exe exists and in PATH.

But if not found then produce an error message telling the user where and how to install it in order to proceed).

+1 Andrey's idea is very good

Given the choices:

* Brittle BAT+Powershell+C# detection script dance. * Including vswhere in distribution. * Requiring vswhere preinstall (either by user or OS or VS2017).

I'd also prefer for the last one. And it's essentially what I'm been pushing Microsoft to do for weeks now.

Scratch that.. I've now tried to make build changes to use the vswhere tool. And it's useless. It has too many bugs. It tells you nothing about specific msvc installs (ie cl.exe). It only tells you about the overall VS2017 install. As far as I can tell, when one install multiple cl.exe-s (as will be possible in some mythical future according to Microsoft) it will not tell you about them individually. You still have to put it the logic for guessing the individual versions by navigating the filesystem. And if we are going to ask users to install this thing it's not worth it. My recommendation...

We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS. That way we can use the existing logic we have for that. And the user doesn't have to install mystery executables. When Microsoft fixes this mess we can support their fix.

Thoughts?

I think that is fine for bootstrap, but seems like it is too stringent for build. We have lots of workflows that need to be able to build against multiple toolsets either in the same command or same script (e.g. toolset=msvc-13.0,msvc-14.0,msvc-14.1 or `for toolset in toolsets: build(toolset)`). Not that I have any desire to add dependencies to COM, but since b2 is an executable, we could link in the necessary resolution logic to windows builds of b2, to avoid using the BAT+PS+C# lookup. Also, just to be clear, if you define the VS150COMNTOOLS variable, the build.bat script won't even attempt the BAT+PS+C# detection. However, it will still try it if you want to build msvc-8.0 on windows XP. Maybe we just need more checks before entering that script....like "is there an appropriate version of powershell on this computer?...if not skip this test completely". Tom

Rene Rivera

5:39 p.m.

On Wed, Apr 5, 2017 at 6:29 AM, Tom Kent via Boost wrote:

...

On Tue, Apr 4, 2017 at 4:13 PM, Rene Rivera via Boost < boost@lists.boost.org

...
wrote:

...
On Tue, Apr 4, 2017 at 9:34 AM, Rene Rivera wrote:

...
On Tue, Apr 4, 2017 at 4:09 AM, Mateusz Loskot via Boost < boost@lists.boost.org> wrote:

...
On 4 April 2017 at 10:59, Paul A. Bristow via Boost wrote:

...
...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev via Boost Sent: 30 March 2017 17:45 To: boost@lists.boost.org Cc: Andrey Semashev Subject: Re: [boost] [VS2017][release] vswhere.exe

On 03/30/17 18:46, Rene Rivera via Boost wrote: > On Thu, Mar 30, 2017 at 10:20 AM, Glen Fernandes via Boost < > boost@lists.boost.org> wrote: > >> Mateusz wrote: >>> The utility is not deployed by any VS installer. >>> You need to download it separately, from GitHub. >> >> I hope that does not mean the Boost release itself would have to contain a >> Windows executable for the purpose of finding VS. > > That is the general recommendation from Microsoft.

IMO, requiring a BLOB executable in a source distribution is unacceptable (regardless of the license of the BLOB). This

...
...
...
...
distribution transparency and may affect its review and certification, if one is performed by Boost users. This also raises a security issue since the executable may be compromised and contain malware.

I consider vswhere a part of the toolchain. We do not distribute toolchains in our releases, and we should not make an exception for MSVC. If MS cannot supply this tool in VS installers or as an OS update, and we still want to use it, make it a precondition for the users to install first and add a link to the Getting Started page. But

compromises please,

...
...
...
...
don't put BLOBs into the source distributions.

+1

(Perhaps install process can assume that, if needed, vswhere.exe exists and in PATH.

But if not found then produce an error message telling the user where and how to install it in order to proceed).

+1 Andrey's idea is very good

Given the choices:

* Brittle BAT+Powershell+C# detection script dance. * Including vswhere in distribution. * Requiring vswhere preinstall (either by user or OS or VS2017).

I'd also prefer for the last one. And it's essentially what I'm been pushing Microsoft to do for weeks now.

Scratch that.. I've now tried to make build changes to use the vswhere tool. And it's useless. It has too many bugs. It tells you nothing about specific msvc installs (ie cl.exe). It only tells you about the overall VS2017 install. As far as I can tell, when one install multiple cl.exe-s (as will be possible in some mythical future according to Microsoft) it will not tell you about them individually. You still have to put it the logic for guessing the individual versions by navigating the filesystem. And if we are going to ask users to install this thing it's not worth it. My recommendation...

We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS. That way we can use the existing logic we have for that. And the user doesn't have to install mystery executables. When Microsoft fixes this mess we can support their fix.

Thoughts?

I think that is fine for bootstrap, but seems like it is too stringent for build. We have lots of workflows that need to be able to build against multiple toolsets either in the same command or same script (e.g. toolset=msvc-13.0,msvc-14.0,msvc-14.1 or `for toolset in toolsets: build(toolset)`).

The requirement would only be for bootstrap. For regular building, for the immediate future, use a fuller detection logic, but still based on paths and registry.

...

Not that I have any desire to add dependencies to COM, but since b2 is an executable, we could link in the necessary resolution logic to windows builds of b2, to avoid using the BAT+PS+C# lookup.

Right.. Not doable for this release though. In the longer term future we'll incorporate the discovery logic into b2 as a builtin that talks to COM plus jam logic to interpret the results. Also, just to be clear, if you define the VS150COMNTOOLS variable, the

...

build.bat script won't even attempt the BAT+PS+C# detection. However, it will still try it if you want to build msvc-8.0 on windows XP. Maybe we just need more checks before entering that script....like "is there an appropriate version of powershell on this computer?...if not skip this test completely".

Maybe.. But I'm looking to simplify stuff. It's complicated enough even before all the new logic :-) I foresee a rewrite where we drop some number of old compilers, for example. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

degski

9:19 p.m.

On 5 April 2017 at 11:39, Rene Rivera via Boost wrote:

...

On Wed, Apr 5, 2017 at 6:29 AM, Tom Kent via Boost wrote: I foresee a rewrite where we drop some number of old compilers, for example.

IMHO, that is a *very* good idea... In my view it is simple, boost (the current boost release) should support the windows/compiler versions (Yes, they are linked. No, that's not how linux works.), that Microsoft supports, no more, no less. Go with the M$-Flow. degski

Rene Rivera

6 Apr 6 Apr

2:12 a.m.

On Tue, Apr 4, 2017 at 4:13 PM, Rene Rivera wrote:

...

We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS. That way we can use the existing logic we have for that. And the user doesn't have to install mystery executables. When Microsoft fixes this mess we can support their fix.

Two updates.. * I implemented the build changes to just use VS150COMNTOOLS, and ProgramFiles env vars for detection. Although I haven't implemented the "ask users" part of this. * MS is going to include vswhere in an upcoming VS update in a known location. Please test latest Boost snapshots and Boost Build. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Tom Kent

2:23 a.m.

On Wed, Apr 5, 2017 at 9:12 PM, Rene Rivera via Boost

...

wrote:

...

On Tue, Apr 4, 2017 at 4:13 PM, Rene Rivera wrote:

...
We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS. That way we can use the existing logic we have for that. And the user doesn't have to install mystery executables. When Microsoft fixes this mess we can support their fix.

Two updates..

* I implemented the build changes to just use VS150COMNTOOLS, and ProgramFiles env vars for detection. Although I haven't implemented the "ask users" part of this. * MS is going to include vswhere in an upcoming VS update in a known location.

That doesn't help us for the installs of VS2017 that are already out there and may not see updates. We definitely can't depend on users getting the VS update in a timely manner. Tom

degski

1:18 p.m.

On 5 April 2017 at 20:23, Tom Kent via Boost wrote:

...

That doesn't help us for the installs of VS2017 that are already out there and may not see updates. We definitely can't depend on users getting the VS update in a timely manner.

To those users that are unable to use google, unable to click a link and download an executable, and those who don't understand what "put the executable in your path" means, the use of most boost libraries is most probably above their pay-grade anyway. You're looking for nails at low tide... degski

Paul A. Bristow

1:54 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of degski via Boost Sent: 06 April 2017 14:19 To: boost Cc: degski Subject: Re: [boost] [VS2017][release] vswhere.exe

On 5 April 2017 at 20:23, Tom Kent via Boost wrote:

...
That doesn't help us for the installs of VS2017 that are already out there and may not see updates. We definitely can't depend on users getting the VS update in a timely manner.

To those users that are unable to use google, unable to click a link and download an executable, and those who don't understand what "put the executable in your path" means, the use of most boost libraries is most probably above their pay-grade anyway. You're looking for nails at low tide...

I disagree - MS IDE users expect it all to 'just work' from the IDE. They rightly don't expect to mess about with funny paths and hideous command windows. That doesn't mean that they are not highly expert with C++ and using Boost libraries - they are just 'differently able' ;-) So we need to make absolutely sure that our instructions are not making unwarranted assumptions about the users skill set. I have long argued that we fail at present. It costs very little. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Andrey Semashev

2:40 p.m.

On 04/06/17 16:54, Paul A. Bristow via Boost wrote:

...

...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of degski via Boost Sent: 06 April 2017 14:19 To: boost Cc: degski Subject: Re: [boost] [VS2017][release] vswhere.exe

On 5 April 2017 at 20:23, Tom Kent via Boost wrote:

...
That doesn't help us for the installs of VS2017 that are already out there and may not see updates. We definitely can't depend on users getting the VS update in a timely manner.

To those users that are unable to use google, unable to click a link and download an executable, and those who don't understand what "put the executable in your path" means, the use of most boost libraries is most probably above their pay-grade anyway. You're looking for nails at low tide...

I disagree - MS IDE users expect it all to 'just work' from the IDE.

They rightly don't expect to mess about with funny paths and hideous command windows.

While I generally agree that the simpler installation and use process the better, a developer who haven't heard of PATH or command line is not a developer. MS has brought the mess with toolset location on its users. We can do only so much to not make things worse from our end. Giving simple instructions to follow is IMHO enough.

Robert Ramey

3:17 p.m.

On 4/6/17 7:40 AM, Andrey Semashev via Boost wrote:

...

On 04/06/17 16:54, Paul A. Bristow via Boost wrote:

...
...
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of degski via Boost Sent: 06 April 2017 14:19 To: boost Cc: degski Subject: Re: [boost] [VS2017][release] vswhere.exe

On 5 April 2017 at 20:23, Tom Kent via Boost wrote:

...
That doesn't help us for the installs of VS2017 that are already out there and may not see updates. We definitely can't depend on users getting the VS update in a timely manner.

To those users that are unable to use google, unable to click a link and download an executable, and those who don't understand what "put the executable in your path" means, the use of most boost libraries is most probably above their pay-grade anyway. You're looking for nails at low tide...

I disagree - MS IDE users expect it all to 'just work' from the IDE.

They rightly don't expect to mess about with funny paths and hideous command windows.

While I generally agree that the simpler installation and use process the better, a developer who haven't heard of PATH or command line is not a developer.

MS has brought the mess with toolset location on its users. We can do only so much to not make things worse from our end. Giving simple instructions to follow is IMHO enough.

An interesting little thread which goes to a large problem with software of all kinds today. The problem is software which "usually works", "mostly works", "can be made to work", etc. Rather than "works" or "just works". tl;dr; If I'm working on a command line system it generally works as advertised. I have to be pretty specific and coordinating all the resources - libraries, compilers, debugging documentation, information lookup while coding, etc. all has to be done "by hand". I have to lookup command syntax all the time. It's straightforward but can be (very) tedious. Enter the IDE, it integrates all the above in a slick package. Very cool and slick - got to love it.... Until - I need something and I can't find it !. It can be hours searching for menus for the proper setting, or tweaking paths, or any number of things. So now I'm back in to spending time on a bunch of stuff I had started using the IDE to avoid! Now I'm told that if I'm a real developer, I should know all this other stuff - That is, it's my fault! The IDE maker has the solution - make the package even more comprehensive and opaque - (that is, "user friendly"). This usually means having deeper menus and settings sprinkled all over the place. This compounds the problem rather than addressing it. The real solution is to spend more time thinking about the IDE and it's design so that there is more of a direct link from what I want to what I do. But programmers don't want to do this. They just want to add more code. When ever there's a complaint - we'll fix it with more code, more settings, more "smart"/"automatic"/"environmentally aware" behavior, etc. Of course it's not just the IDE it's everything websites, apps, everything. Look at our own tools - they're more obscure than the problems they are trying to address. (Include CMake and other build tools as well). The only real solution is more literate programmers, more feedback from users, and more willingness on the part of programmers to accept the fact that if it doesn't work for the user - the job isn't done. A program is not just a collection of random features but needs to embody a logical concept that the human brain can capture. Robert Ramey

Peter Dimov

2:32 p.m.

Tom Kent wrote:

...

That doesn't help us for the installs of VS2017 that are already out there and may not see updates. We definitely can't depend on users getting the VS update in a timely manner.

We could first try the usual install locations, then if no installation is found there, try to use vswhere.exe, and if that also fails, well, there's always the fallback of using the 2017 command prompt. This would cover 99.4% of the users.

Rene Rivera

2:41 p.m.

On Thu, Apr 6, 2017 at 9:32 AM, Peter Dimov via Boost

...

wrote:

...

Tom Kent wrote:

That doesn't help us for the installs of VS2017 that are already out there

...
and may not see updates. We definitely can't depend on users getting the VS update in a timely manner.

We could first try the usual install locations, then if no installation is found there, try to use vswhere.exe, and if that also fails, well, there's always the fallback of using the 2017 command prompt. This would cover 99.4% of the users.

That's roughly the longer term plan. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Olaf van der Spek

6:29 a.m.

On Thu, Apr 6, 2017 at 4:12 AM, Rene Rivera via Boost wrote:

...

On Tue, Apr 4, 2017 at 4:13 PM, Rene Rivera wrote:

...
We just ask users to run the bootstrap/build from the VS command prompt which defines VS150COMNTOOLS. That way we can use the existing logic we have for that. And the user doesn't have to install mystery executables. When Microsoft fixes this mess we can support their fix.

Two updates..

* I implemented the build changes to just use VS150COMNTOOLS, and ProgramFiles env vars for detection. Although I haven't implemented the "ask users" part of this. * MS is going to include vswhere in an upcoming VS update in a known location.

Please test latest Boost snapshots and Boost Build.

Link?

Daniel James

8:43 a.m.

On 6 April 2017 at 07:29, Olaf van der Spek via Boost wrote:

...

On Thu, Apr 6, 2017 at 4:12 AM, Rene Rivera via Boost

...
Please test latest Boost snapshots and Boost Build.

Link?

There are links to the snapshot download and documentation on the testing page: http://www.boost.org/development/testing.html

Andrey Semashev

29 Mar 29 Mar

2:59 p.m.

On 03/29/17 16:43, degski via Boost wrote:

...

On 28 March 2017 at 08:34, Rene Rivera via Boost wrote:

...
And at least because of license issues I'm not comfortable including it in the Boost tree, or install.

Why don't you simply ask them, whether it is OK to include vswhere.exe in the boost distribution?

Please, no binaries in source distributions. This removes the transparency that is expected from such distributions. Everything that is needed to build Boost from sources should be present on the developer's machine. If MS fails to provide all required components for that, the users will have to suffer.

2775

Age (days ago)

2784

Last active (days ago)

List overview

Download

38 comments

15 participants

participants (15)

Andrey Semashev
Beman Dawes
Daniel James
degski
Glen Fernandes
Klaim - Joël Lamotte
Marcel Raad
Mateusz Loskot
Olaf van der Spek
Paul A. Bristow
Peter Dimov
Rene Rivera
Robert Ramey
Steve M. Robbins
Tom Kent