Conan: Add support for Visual Studio toolsets

[torbjoernk]

_This is based on the following SO: How to specify Visual Studio compiler toolset with Conan for CMake?_

Visual Studio offers the notion of toolsets, e.g. for Visual Studio 2015 and the optional "Windows XP Support for C++" package, there are the toolsets v140 and v140_xp. In case, someone added the "Clang with Microsoft CodeGen" package, there is v140_clang_c2.

With CMake, I can use the -T command line flag to specify the toolset to be used for the solution files generated with CMake, e.g. cmake -T v140_clang_c2 will generate the project solution file with "Visual Studio 2015 - Clang with Microsoft CodeGen (v140_clang_c2)" configured as the "Platform Toolset" for all targets.

How can I tell Conan on Windows with an appropriate installed Visual Studio to use a specific toolset? Preferably for conanfiles using CMake as the generator.

The only way I could come up with is to add an additional option to all the projects/conanfile.py I'd like to use with different toolsets and add another package option (e.g. used as -o toolset=v140_clang_c2) to be added to the command line of the initial invocation of CMake.

I'd expect that variability to be part of the package manager itself rather than the responsibility of the package writers.

SO user drodri suggested the following workaround:

No, conan does not provide this functionality out of the box.

If you want to use them now, conan could be customized to handle different toolsets, I'd do the following:

First, extend the current settings, to account for the toolsets. I wouldn't use options if you are using different toolsets extensively. You could try to define them as global to Visual Studio:

compiler:
    ...
    Visual Studio:
        runtime: [MD, MT, MTd, MDd]
        version: ["8", "9", "10", "11", "12", "14", "15"]
        toolset: [None, v140, v140_xp]

Or if you want to be more specific, define them per version, something like:

compiler:
    ...
    Visual Studio:
        version: 
            "12": 
                toolset: [None, v120, v120_xp] 
            "14": 
                toolset: [None, v140, v140_xp]

Then, it is true that the responsibility to pass the option to cmake, is for the package creator. I would of course just add

"-T %s" % self.settings.compiler.toolset
# or
"-T %s" % self.settings.compiler.version.toolset

to the cmake command arguments.

What would be necessary to extend conan to support Visual Studio toolsets out-of-the-box without the need of users to alter the settings.yml and without package managers to add the -T parameter to the call to CMake manually?

I'd be happy to provide a PR in case this feature is something the conan maintainers are willing to integrate.

[memsharded]

Hi @torbjoernk ,

First thing would be to understand the different available toolsets, are they just for vs14? Are there other toolsets for other vs versions? Would it be better the nested or the flat settings layout?

Also, very importantly, I would like to have more feedback and support from other users using these toolsets and interested in this feature.

[torbjoernk]

Thanks for the quick response, @memsharded!

The Visual Studio (VS) toolsets are "_cumulative_" (in case this is the correct word). Having multiple versions of VS installed, the most recent one can also use the toolsets provided by the older ones.

Each major version of VS brings its own default toolset (VS2010 -> v100, VS2012 -> v120, VS2015 -> v140, VS2017 -> v141). Some VS extensions (e.g. XP support, Clang code generation, 3rd-party LLVM extension) bring their own toolsets.

The selection of the VS toolset determines the version of the Visual C++ (VC++) runtime library required on the target systems. In case it is required to support systems where the installation of VC++ runtime for VS2015 is not possible but the one for VS2012 is installed, it is necessary to use v120 in VS2015.

Having VS2010, VS2012 (with the optional XP support) and VS2015 (with the optional XP support and Clang CodeGen) will result in the following toolsets available within VS2015:

Toolset | Provider
--------|---------
v100 | VS2010
v120 | VS2012
v120_xp | XP support extension for VS2012
v140 | VS2015
v140_xp | XP support extension for VS2015
v140_clang_c2 | Clang CodeGen extension for VS2015

After installing VS2017 RC, the toolset v141 is added to that list of available toolsets in VS2017 - but not in the other VS, e.g. VS2015)

My team still needs to support legacy systems on WinXP and wants to switch to Conan for our dependency management. Thus, the selection of v140_xp is crucial for us. In addition, for increased portability, we'd like to use other toolsets, e.g. v140_clang_c2.

[memsharded]

Thanks for the detailed feedback. Given that, I'd say it makes more sense the "flat" settings, with just a global toolset for all versions, irrespective of the provider (specific vs version).

[torbjoernk]

Just to understand you correctly: The global "flat" toolset variable for VS compilers should then hold all known toolsets:

compiler:
    ...
    Visual Studio:
        runtime: [MD, MT, MTd, MDd]
        version: ["8", "9", "10", "11", "12", "14", "15"]
        toolset: [None, v100, v110, v120, v120_xp, v140, v140_xp, v140_clang_c2] 

That way, where would be the check whether the selected compiler.version supports the selected compiler.toolset? In the conan generator, i.e. CMakeGenerator or VisualStudioGenerator?

[memsharded]

Yes, that is right, I think it is simpler that way. I suggest not doing the check, let the users define them. If they do it wrong, no problem, cmake or the build will surely raise an Error anyway.

This is more or less a conan design policy, avoiding excessive checks helps not blocking users when something is not complete or conan fails to provide it completely. For example, you can build a Release library and use a MXd runtime if you want. Probably it will fail, but it is the users responsibility.

In this case, not checking will allow to easily add toolsets in the settings.yml file when they are released without having to touch the conan codebase.

[lasote]

Using v120 in VS2015 won't generate the same binaries than directly installing VS12? right?

[memsharded]

Yes, that is a very important thing @torbjoernk , if they generate the same binaries, we would need a different approach. The settings are mapped to the binary package ID, having two different settings (VS15-v120 toolset, and VS12) will generate two different package IDs, while they should actually be the same.

[ras0219-msft]

v120 inside the VS2015 IDE/MSBuild will invoke the _toolchain_ from 2013 exactly* the same as if you built from VS2013 IDE/MSBuild. The binaries built using v120 should be exactly identical regardless of which MSBuild they are built using.

You probably care only about the toolset version and not at all about the IDE version (except that you _may_ need to invoke the MSBuild of >= the toolset version). Wherever you are saying "VS2012", you probably really mean the v110 toolset, regardless of the IDE.

The point above about runtimes is that (until 2015/2017) each toolchain corresponds with a completely incompatible CRT, so you can't mix and match. VS2017 has retained full binary compatibility with 2015, corresponding with a minor bump in the toolset version (v140 -> v141).

_* There are a few very subtle MSBuild differences, but most projects shouldn't notice._

[Type1J]

Any progress here? I attempted (from /build):

conan install -s compiler='clang' ..

I got the following error:

ERROR: Conanfile: 'settings.compiler.libcxx' value not defined.

Right afterward I found this issue.

For reference, I can normally do this line for non-Conan project, and I'd expect this to also be the command following the one above:

cmake -G "Visual Studio 15 2017 Win64" -T "LLVM-vs2014" ..

The above was for a Win64 target, but my PS4 SDK has a toolchain called "Clang" also. Adding support for toolsets in Windows would be a great benefit for Conan.

[memsharded]

I think the line:

$ conan install -s compiler="clang"

should be used to directly define the clang compiler, not the MSVC compiler with the clang toolset. For that, I guess the line could be more like the one you defined:

$ conan install -s compiler="Visual Studio" -s compiler.version=15 -s compiler.toolset="LLVM-vs2014"

I agree this would be useful, we should revise this.

[milancpp]

Are there any plans to implement the compiler.toolset option @memsharded? This is a bit of a blocker in my organisation since we need to support earlier toolsets but only have access to Visual Studio 2017.

Thanks very much!

[memsharded]

Right now, the CMake helper has added an option for toolsets (still undocumented :( ), which could be used in the package recipe if using custom settings with little code, you might try today.

I am adding this to next 0.29 release (current 0.28 is packed), at least to provide some docs and examples how to manage this, so it is not a blocker. If you need it sooner, please tell. Thanks!

[jeroendv]

the following may be a useful Visual Studio versioning reference

[lasote]

Should it be added to the tools.build_sln_command with the /p:PlatformToolset as well, right?

[milancpp]

Just tested 0.29 for the toolset support. Very happy so far, everything works great (as soon as one figures out to delete the old settings.yml)

Thank you!

[memsharded]

Excellent, thanks for the feedback!
Yes, it seems we forgot to add a migration :( Lets see if it is worth to add it.

[memsharded]

We have opened a minor 0.29.1 that includes an automatic migration for this. Will release maybe tomorrow. Thanks for telling about this issue :)

[jeroendv]

2057 is a slighly modified visual_studio_multi generator that uses the Visual studio toolsets information instead of the visual studio version information.

This way a user can work on a project compiled against the v120 toolset using the latest visual studio 2017 IDE

[memsharded]

Support for VS toolset released in 0.29, testing and feedback welcome