Re: [boost] Status of Visual Studio 2017 support

Subject: Re: [boost] Status of Visual Studio 2017 support
From: Olaf van der Spek (ml_at_[hidden])
Date: 2017-02-20 10:25:38

On Fri, Feb 17, 2017 at 2:57 PM, Nat Goodspeed <nat_at_[hidden]> wrote:
> On Fri, Feb 17, 2017 at 3:37 AM, Olaf van der Spek via Boost
> <boost_at_[hidden]> wrote:
>
>> On Thu, Feb 16, 2017 at 4:03 PM, Andrew Pardoe via Boost
>> <boost_at_[hidden]> wrote:
>
>> > [Olaf] Wouldn't it make sense to have one VS install, chosen by the user of course, be the default?
>
>> > The problem is in locating that one VS install.
>
>> On Linux one can just do g++ a.cpp, wouldn't it be nice if something
>> similar could be done on Windows?
>>
>> All kinds of command line tools need to do all kinds of tricks to find
>> other tools it seems (on Windows).
>
> In a (non-Boost) project with which I've helped, there's a script that
> does the following:
>
> 0. The user specifies desired VS version by setting an environment
> variable to (e.g.) "120" for VS 2013.
> 1. The script concatenates "VS" + version + "COMNTOOLS" to form an
> environment variable name.
> 2. In the directory indicated by that environment variable, it finds
> VCVarsQueryRegistry.bat.
> 3. It runs VCVarsQueryRegistry.bat in a child process that reports
> VCINSTALLDIR to the parent script.
> 4. Finally it runs %VCINSTALLDIR%\vcvarsall.bat, passing either x86 or
> x64 depending on the user.
>
> If that doesn't work with VS 2017, or for that matter with VS 2015,
> they'll need an algorithm that *does* work.

Wouldn't it be much simpler if you let the user pick the right dev
environment prompt from the start menu and have all stuff available
without having to call extra scripts?

-- 
Olaf