Re: [boost] [VS2017][release] vswhere.exe

Subject: Re: [boost] [VS2017][release] vswhere.exe
From: Tom Kent (lists_at_[hidden])
Date: 2017-04-05 11:29:01

On Tue, Apr 4, 2017 at 4:13 PM, Rene Rivera via Boost <boost_at_[hidden]
> wrote:

> On Tue, Apr 4, 2017 at 9:34 AM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
>
> >
> > On Tue, Apr 4, 2017 at 4:09 AM, Mateusz Loskot via Boost <
> > boost_at_[hidden]> wrote:
> >
> >> On 4 April 2017 at 10:59, Paul A. Bristow via Boost
> >> <boost_at_[hidden]> wrote:
> >> >> -----Original Message-----
> >> >> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of
> >> Andrey Semashev via Boost
> >> >> Sent: 30 March 2017 17:45
> >> >> To: boost_at_[hidden]
> >> >> 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_at_[hidden]> 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