CMAKE_PROJECT_TOP_LEVEL_INCLUDES

[jpr42]

The default method vcpkg tells CMake users to add the vcpkg.cmake module is with a toolchain

 cmake -B [build directory] -DCMAKE_TOOLCHAIN_FILE=[path to vcpkg]/scripts/buildsystems/vcpkg.cmake 

This works. But I believe a new CMake feature suits this code injection better.

 cmake -B [build directory] -D CMAKE_PROJECT_TOP_LEVEL_INCLUDES=[path to vcpkg]/scripts/buildsystems/vcpkg.cmake

The main downside is that CMAKE_PROJECT_TOP_LEVEL_INCLUDES can't be set as an environment variable. And it was introduced in 3.24

Thoughts?

[jpr42]

Link to CMAKE_PROJECT_TOP_LEVEL_INCLUDES variable.

[Neumann-A]

You can probably use that but be wary of try_compile configure checks.

[dg0yt]

Before CMake 3.24, there is already CMAKE_PROJECT_INCLUDE.

IIUC vcpkg.cmake is not only code injection, but also actual toolchain setup. I wonder if it could be beneficial to separate these concerns?

[Neumann-A]

whole-project mode of try_compile(), yes?

Yes

it might be helpful to note

I cannot remember which port it was. I can just remember that it was something simple like find_package(ZLIB|ZSTD|Bzip2|JPEG) (some compression stuff; some build-in CMake module) probably to test if the compression lib was build with a certain compression feature enabled or to detected an optional dependency. I only stumbled over it since the feature set after configure between release/debug build was different since one of the try_compiles yielded a different result between those two configs on windows. The reason the debug build failed the try_compile was due to a mismatch of runtime libraries (e.g. tried to link a release lib with debug runtime which fails). Added a vcpkg-cmake-wrapper to fix CMakes default behavior and moved on since it wasn't a big deal for me and a common issue/fix within vcpkg.

Be aware that CMake itself as find_package in a try_compile check https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/Checks/Curses/CMakeLists.txt#L8
https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/Checks/Curses.cmake#L21

[Neumann-A]

After further thinking it could have been one of the qt modules like, e.g. qtmultimedia:
https://github.com/qt/qtmultimedia/blob/531ea0bd937653c0462edf07cae28e473d4b9979/config.tests/alsa/CMakeLists.txt#L16-L18
using find_package quite extensively.

[dg0yt]

@Neumann-A Is it a problem related also to canonical CMake usage (find modules, config), or strongly connected to vcpkg's use of find_package wrappers?

[Neumann-A]

Is it a problem related also to canonical CMake usage (find modules, config), or strongly connected to vcpkg's use of find_package wrappers?

Lets just say try_compile was kind of stupid in earlier version of CMake without taking anything into account. The remaining issue has just to do with the use of wrappers in vcpkg correcting cmake behavior. I actually don't currently now if CMAKE_MODULE_PATH or other var controlling find_package() behavior are forwarded or not (but that might also be left up for the project doing the try_compile).

[craigscott-crascit]

See this change which aims to address the concerns expressed here, allowing a dependency provider to propagate down into whole-project try_compile() calls.