Scikit-build-core already supports the cmake.prefix entry point, which appends the value to CMAKE_PREFIX_PATH. In theory, this will allow projects that install lib/cmake/<package>/<package>-config.cmake to automatically be found by consuming projects. However, this does not work in cases where:

1. The package uses a non-standard convention
2. The package installs in lib64/cmake/<package>/<package>-config.cmake, and the consuming package is built on a Debian-based system, because in this case, FIND_LIBRARY_USE_LIB64_PATHS is set to FALSE

In theory, the exporting project could set cmake.prefix to <wheel-name>/lib64/cmake/<package>, because the find_package() search procedure does look directly in the values of CMAKE_PREFIX_PATH in addition to the various subdirectories listed. However, that is only conventional on Windows, and I don't consider it good practice to set CMAKE_PREFIX_PATH to <wheel-name>/lib64/cmake/<package>, when prefixes are really meant to have lib64/cmake/<package> within them.

I propose an alternative: a new entry point called cmake.package, that is used like so in entry_points.txt:

[cmake.package]
ExamplePackage = "example/lib64/cmake/example"

In this case, scikit-build-core would pass -DExamplePackage_DIR=/home/user/.local/lib/python3.12/site-packages/example/lib64/cmake/example to CMake. The *_DIR variable tells CMake exactly where to find a package file, rather than giving it a list of prefixes to search through their subdirectories. There's no ambiguity, and it works with any package layout, as long as the config file is named <Package>Config.cmake or <package>-config.cmake.

But it gets even better! With the CMake File API, we can even automatically figure out if the project is exporting any package config files. By searching through the installer keys, it can search for file installers that install <package>-config.cmake or <Package>Config.cmake, and export installers that install <package>-targets.cmake or <Package>Targets.cmake. If it finds the two together, it's a pretty safe bet that that's a CMake package config file, and scikit-build-core can automatically create an entry point for it. (Note that this would be more ambiguous if the <package>-config.cmake convention is used, since that loses casing information. In that case, we could defer to the export name, or just not support the <package>-config.cmake convention.)

Note that if the heuristics used by the automatic entry point creation are incorrect for any reason, the package creator can still manually specify a cmake.package entry point to override the automatic creation procedure.