Did you test this locally, with non-trivial ports/projects? I think this is too simple with regard to recursive find_package/find_dependency calls. In particular the latter must never use REQUIRED but has to check <Pkg>_FOUND.

Did you test this locally, with non-trivial ports/projects? I think this is too simple with regard to recursive find_package/find_dependency calls. In particular the latter must never use REQUIRED but has to check <Pkg>_FOUND.

With the limited resources of a Codespace I tested ports like sdl2 or OSG successfully. Can you recommend some ports that fit in 20 GB of storage and build in a reasonable amount of time?

qtbase. Probably already breaks with minimal features....
But from experience I can tell you that this is a waste of time. I tried to force CMAKE_REQUIRE_FIND_PACKAGE_ in the qt ports but qt seems to call find_package first with the CONFIG keyword and after that without that which is perfectly fine for CMake, e.g.

find_package(package CONFIG)
find_package(package REQUIRED)

and you cannot deal with that correctly. The same goes for COMPONENTS and OPTIONAL_COMPONENTS

qtbase. Probably already breaks with minimal features.... But from experience I can tell you that this is a waste of time. I tried to force CMAKE_REQUIRE_FIND_PACKAGE_ in the qt ports but qt seems to call find_package first with the CONFIG keyword and after that without that which is perfectly fine for CMake, e.g.

find_package(package CONFIG)
find_package(package REQUIRED)

and you cannot deal with that correctly. The same goes for COMPONENTS and OPTIONAL_COMPONENTS

Since find_package is a macro we might be able to record the package name between calls?

Even if some ports break I think the majority of ports is simple enough to work with this. We can set a flag to disable this check for some complex ports like qt.

Since find_package is a macro we might be able to record the package name between calls?

What about recursive and nested find_package calls ?

Even if some ports break I think the majority of ports is simple enough to work with this.

user code also interacts with vcpkg.cmake so it needs to be off by default. Also you could just inject cmake_language(DEFER) and check the property https://cmake.org/cmake/help/latest/prop_gbl/PACKAGES_NOT_FOUND.html

My new approach based on @Neumann-A's suggestions:

• Define a variable outside vcpkg's find_package that stores the package names and relevant arguments like CONFIG, REQUIRED, (OPTIONAL_)COMPONENTS
• Add a package on each invocation of find_package to this list.
• Use z_vcpkg_find_package_indent to filter top-level calls ([vcpkg] Controlling top-level find_package #27950 [vcpkg tool] Add optional tracing of find_package #27982)
• Use cmake_language(DEFER) to process <PackageName>_FIND_REQUIRED and <PackageName>_FIND_REQUIRED_<c>: https://cmake.org/cmake/help/latest/command/find_package.html#package-file-interface-variables
• Issue a warning if a package is inside PACKAGES_NOT_FOUND or <PackageName>_FIND_REQUIRED / <PackageName>_FIND_REQUIRED_<c> are false

Only enable this check if VCPKG_TRACE_FIND_PACKAGE is on.

Depends on #27950 and #27982

I believe this PR is replaced by #27950 . Thanks for your contribution to vcpkg!