Vcpkg: Can't find boost with VS2017.

[codicodi]

CMake's FindBoost looks for libraries tagged with -vc150- when configuring for VS2017, while our Boost always uses vc140 tag (so I guess it compiles itself with VS2015). This is still the case with 1.63 update.

I'm not familiar with Boost's buildsystem but maybe it needs to be explicitly told which toolset should be used?

[ras0219-msft]

Sigh. It looks like we have two issues here; first, we need to fix the boost portfile to build with VS2017. Second, we need to make the user's find_package(Boost) work regardless of whether Boost was built with v140 or v141 (the official term for VS2017's default toolchain).

As much as we've tried to avoid it, I suspect the only way to properly handle Boost is to special-case it in our CMake Toolchain file and override the configuration variables for the consuming project. We've been avoiding special treatment on a per-library basis here, but I don't see much of an alternative.

In this particular case, it looks like the best option is to set Boost_COMPILER to "-vc140" and to always rename the output .lib files to look like they used the vc140 toolset. The DLL names will remain unchanged, however, so they can still sit side-by-side at deployment time for users who are relying on that behavior.

This would correctly enable the cross scenarios of v141 boost -> v140 project and v140 boost -> v141 project.

[KindDragon]

Related boost issue https://github.com/boostorg/build/issues/157

[OlafvdSpek]

This would correctly enable the cross scenarios of v141 boost -> v140 project and v140 boost -> v141 project.

Should those scenarios be supported at all?
AFAIK major versions of MSVC are not guaranteed to be compatible.

How is this done for other libs?
IMO the libs should be separated per compiler, like it done with the triplets for platforms.

[KindDragon]

AFAIK major versions of MSVC are not guaranteed to be compatible.

v141 guaranteed to be compatible with v140 and backward

[OlafvdSpek]

Yes, but 2013 and 2015 aren't compatible so this structural problem will have to be solved some time.

[ras0219-msft]

For totally incompatible toolchains (for example, v120, v140, and clang-android) we can handle those with entirely separate triplets. For example, x86-win-v120 and x64-win-v120-static. This ensures that you can, within a single vcpkg enlistment, make a functional zlib available for every version of VS you use and for every compilation target.

The rationale behind merging v141 and v140 is that they _are_ completely compatible with each other, so there's little benefit to segregate them by default. We do have a highly-experimental-undocumented option [1] that can be added to your triplet file to try to force the v140 toolset even if you have v141, but it doesn't seem worth investing in making it "production quality" so far.

[1] If you want to play with it (note: will change at any time), it's set(VCPKG_TOOLSET_VERSION v140) in a triplet file.

[ras0219-msft]

Ok, I've checked in the first half of the above change with b2b2c91. Boost_COMPILER will now be overridden to be -vc140 for all packages and all projects built using our toolchain file. I confirmed this fixed cpprestsdk, and I'm currently confirming that it fixes #626.

I have the second half of this prepped locally (renaming the -vc150 libs to -vc140), however we currently _aren't_ building boost using VS2017 so I have not been able to test that yet. I'm seeking to simultaneously add 2017 builds for boost as well as adding the renaming, which should prevent regression here.

That said, the fix in b2b2c91 does resolve the original issue posted here, so I'll close this issue. Please let me know if you find a package that is still not correctly locating the boost libraries.

[KindDragon]

Boost libraries will be named -vc140 for VS2017 (at least for now)
https://github.com/boostorg/config/blob/d3c1db5436a2fb4682e15590f2d344d749579b31/include/boost/config/auto_link.hpp#L164-L167

[KindDragon]

PR about that https://github.com/boostorg/config/pull/110

[ras0219-msft]

Thanks for communicating with the boost project, @KindDragon!