Boost logo

Boost :

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at