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

Subject: Re: [boost] [VS2017][release] vswhere.exe
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2017-04-05 17:39:33

On Wed, Apr 5, 2017 at 6:29 AM, Tom Kent via Boost <boost_at_[hidden]>
wrote:

> 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)`).
>

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