Dependency providers don't propagate into whole-project try_compile() calls
Background and motivating discussion from vcpkg can be found here: https://github.com/microsoft/vcpkg/discussions/26681#discussioncomment-4115398. At the moment, it appears this means package managers like vcpkg may see this as a blocker to supporting the dependency provider mechanism (not an official statement, see the linked thread).
When using the whole-project signature of try_compile()
, the project being used could call find_package()
. If a dependency provider is being used in the main project, it may be reasonable to expect it to be used in the try_compile()
project as well. Otherwise, you can end up with different things being provided for the same dependency. I've asked for a specific example in the above discussion to help flesh out a concrete scenario.
Dependency providers can only be set by a file included from CMAKE_PROJECT_TOP_LEVEL_INCLUDES
. But we don't propagate CMAKE_PROJECT_TOP_LEVEL_INCLUDES
into whole-project try_compile()
calls. This was an oversight when I implemented those two features in CMake 3.24. I propose adding a policy which would pass it through when the policy is NEW
. Any code included through CMAKE_PROJECT_TOP_LEVEL_INCLUDES
can check the IN_TRY_COMPILE
global property if they need to customise their behavior depending on which context they are in. Similar to the CMP0141
policy, this new proposed policy should be checked at the first project()
call and apply unilaterally to the rest of the project processing.
It is worth mentioning that in CMake 3.25, we are adding a new whole-project signature for try_compile()
. I'm assuming it is too late in the release cycle to make that new signature pass through CMAKE_PROJECT_TOP_LEVEL_INCLUDES
. We would still have to address doing that with the old signature in a future release anyway, so it may be cleaner to handle both with a single policy that we add in CMake 3.26. But I'm willing to support adding a policy for this in 3.25 if others think that is appropriate.