(Windows) bjam should choose the msvc version from the current visual studio prompt

[desurium@…]

If you have multiple versions of msvc installed bjam seems to choose itself the version of msvc and do not take the current environment into account.

This behaviour is totally misleading, beacuse I open a specific Visual Studio prompt with a reason.

Bjam should pick the current msvc version out of the msvc prompt by default.

Example: I want to build boost through the cmake ExternalProject mechanism. I have msvc11 and msvc12 installed. Even after I opened a msvc12 prompt, bjam picks msvc11. This will result into linking errors later in the cmake build process because of runtime mismatches.

[Steven Watanabe]

Boost.Build does not use the environment to find Visual Studio. If you want a specific version, please specify it on the command line.

b2 toolset=msvc-12.0 

[desurium@…]

I do know this command line option. I just don't find it very usefull in an automatic build environment or on a developer machine, where you want to build your dependencies as well.

It would be sufficient to have a new command line option like "compiler-detection={auto,cli,off}". I could try to implement such a command line option.

But with only "toolset" as the only option, everybody has to check the current active compiler in such an build environment and pass the already choosen compiler version (it was explicitly choosen before by selecting a msvc cli or setting CXX) to bjam again.

But something new came into my mind: How does bjam searches for gcc if multiple gcc installations are installed? Does it check CXX? Does it chooses the global activated gcc?

I don't think, that is the "best way". Selecting the newest versions if it is possible to say, that the user wants a different compiler isn't intuitive and leads to errors you may notice only very late.

Especially for the STL library it can cause different problems if you mix binaries compiled with different STLs.

Anyway I don't see any benefit with the current behaviour. What advantages does it have over checking the current active msvc compiler from the environment?

[vz-boost@…]

FWIW I also find the current behaviour annoying. It's too easy to forget to specify the toolset, especially when using many different MSVC versions in parallel, it should really be taken from the environment automatically.

[dave@…]

I've just crashed into this *feature* with Boost 1.59.0 when wanting a VS2103 build with VS2015 also installed. Setting toolset=msvc-12.0 didn't work; b2 reported:

notice: [msvc-cfg] msvc-14.0 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe'
notice: [msvc-cfg] msvc-12.0 detected, command: 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\cl.exe'
notice: will use 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe' for msvc, condition <toolset>msvc-14.0

and happily used the version I did not specify.

The solution is to edit project-config.jam and set:

using msvc : 12.0 ;

[Thales Sabino]

I just want to report that this is also happening with me. I have VS2013 and VS2015 installed in my machine and the build engine isn't choosing the corrent version set in the cmd.

[Thales Sabino]

I also note the following:

When there is more than one version of VS installed, there will be environment variables corresponding to each version. In my machine I have the following ones:

VS110COMNTOOLS -> I think it is for backward compatibility for VS2013

VS120COMNTOOLS -> Visual Studio 2013

VS140COMNTOOLS -> Visual Studio 2015

So, I tried to temporarilly remove the VS140COMNTOOLS variable and the Boost Build Engine started to work. This means that regardless of the VS version it will always use the most recent one.

Since I'm using a controlled build environment, I have the ability to remove this environment variable while building boost.

Hope this can help someone with the same problem.