|
Boost : |
Subject: Re: [boost] [VS2017][release] vswhere.exe
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2017-04-04 09:09:34
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
Best regards,
-- Mateusz Loskot, http://mateusz.loskot.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk