What is the point of using vcpkg.cmake as a toolchain?

[invy]

vcpkg documentation suggest, that to integrate vcpkg ports into project one should use vcpkg.cmake toolchain file and a triplet.

Examining vcpkg.cmake contents shows, that it has some 'hacks' for some ports and including vcpkg-cmake-wrapper.cmake. But other then that it's just setting CMAKE_PREFIX_PATH=/path/to/vcpkg/installed/tripplet-name

Out of more than 1000 ports there is only 37 which use wrappers and hacks for 5 ports: Boost, ICU, GSL, CURL and grpc.

Wounldn't it be better to get rid of the toolchain file:

• Instead of specifying triplet and toolchain path, user should just provide the prefix (which is basically the same but the standard cmake way of pointing cmake to the configuration)
• instead of providing vcpkg-cmake-wrapper.cmake, maintainers could implement more or less correct cmake configuration for those 37 packages
• fix those 5 packages (hardcoding such things in toolchain file looks ugly anyway)

Benefits are pretty self explanatory: use standard cmake approach (CMAKE_PREFIX_PATH) to find package instead of toolchain, which looks like a hack (considering hacks are used to make it work, e.g. if( CMAKE_IN_TRY_COMPILE ) and so on.

[Neumann-A]

you forgot the macro overrides the vcpkg toolchain installs for add_library and add_executable (->option VCPKG_APPLOCAL_DEPS). It also tries to figure out a default triplet if you do not supply one.
If you don't want to use the toolchain, don't use it. It is simply up to you.

fix those 5 packages (hardcoding such things in toolchain file looks ugly anyway)

should be moved into vcpkg-cmake-wrapper.cmake

instead of providing vcpkg-cmake-wrapper.cmake, maintainers could implement more or less correct cmake configuration for those 37 packages

or upstream could just fix their cmake targets or find_modules....

[invy]

If you don't want to use the toolchain, don't use it. It is simply up to you.

Ah, ok, Could you add it to the documentation in this case.

or upstream could just fix their cmake targets or find_modules....

agreed

[ensafi]

Is there an officially sanctioned way to use Vcpkg with CMake using something like include(vcpkg) which in turn updates by CMAKE_MODULE_PATH and/or CMAKE_PREFIX_PATH to find Vcpkg-installed packages without any additional effort?

The toolchain approach has at least one major drawback, as already reported in issue #557 which was closed for some reason even though the problem is very real and reproducible when a project contains a mix of languages such as C++ and C# (and possibly other situations such as using Intel C++ or other compilers instead of MSVC, but I have not tested the latter). When building from the Visual Studio GUI, the location of dumpbin.exe (which happens to be next to the C++ compiler cl.exe) is only added to PATH for C++ projects. As a result, attempting to build a C# project results in an error from applocal.ps1 stating that dumpbin.exe could not be found. Luckily, the error is ignores, and the build is deemed successful, but it is a nuisance.

If we could simply link to Vcpkg-installed libraries without the extra functionality provided by the toolchain hack, including the invocation of applocal.ps1 under Windows, it may be sufficient for a wide range of applications without adversely impact C# projects. Is there an "official" solution that will not break with future releases of Vcpkg?

[TheJCAB]

I have also been struggling with the concept of integrating vcpkg as a toolchain file. It's... uncomfortable if nothing else. It would be great to see a good resolution to this question.

In my opinion, please either document how to accomplish vcpkg integration via find_package() or include() after project(), stating any resulting drawbacks or incompatibilities, or document the reasons why a toolchain file is absolutely necessary.

Thanx!