Is there a reason you use the complicated way instead of doing two find_library(${ARGN}) calls with the first one being with NO_DEFAULT_PATHS and only the vcpkg path as PATHS?

Is there a reason you use the complicated way instead of doing two find_library(${ARGN}) calls with the first one being with NO_DEFAULT_PATHS and only the vcpkg path as PATHS?

I hoped to explain it in the top post. Basically, I want to put the responsibility for correct vpckg library lookup into a single place, instead of scattering it over all wrappers.

Again taking the gdal example. We come from:

find_library(GDAL_LIBRARY_DEBUG
    NAMES gdal_d gdal_i_d gdal
    NAMES_PER_DIR
    PATHS "${CMAKE_CURRENT_LIST_DIR}/../../debug/lib"
    NO_DEFAULT_PATH)

Problem: Doesn't systematically respect VCPKG_PREFER_SYSTEM_LIBS. Doesn't systematically find the vcpkg lib when gdal is built only for release. (Needed to avoid picking a non-vcpkg debug lib. There will be another find_library call from _find_package.)

You propose (and I add gdal_i to cover all release lib names for gdal):

find_library(GDAL_LIBRARY_DEBUG
    NAMES gdal_d gdal_i_d gdal_i gdal
    NAMES_PER_DIR
    PATHS "${CMAKE_CURRENT_LIST_DIR}/../../debug/lib" "${CMAKE_CURRENT_LIST_DIR}/../../lib"
    NO_DEFAULT_PATH)
find_library(GDAL_LIBRARY_DEBUG
    NAMES gdal_d gdal_i_d gdal_i gdal
    NAMES_PER_DIR)

Problem: Doesn't systematically respect VCPKG_PREFER_SYSTEM_LIBS. Verbose syntax.

I propose:

z_vcpkg_find_library_debug(GDAL_LIBRARY_DEBUG
    NAMES gdal_d gdal_i_d gdal_i gdal
    NAMES_PER_DIR)

Problem: Needs helper functions. (This PR.)

... and everything duplicated for release, and done in every wrapper.

You propose

No i mean that you do two find_library calls in z_vcpkg_find_library_<config> instead of manipulating the lists.

You propose

No i mean that you do two find_library calls in z_vcpkg_find_library_<config> instead of manipulating the lists.

Okay.

This leaves the problem that it doesn't respect VCPKG_PREFER_SYSTEM_LIBS.
Guarding the first call with if(VCPKG_PREFER_SYSTEM_LIBS) doesn't help, because then we fall back to the default search path. The default search path contains the debug-release search order for the consuming project, not for the desired library. So it is wrong either for release or for debug.

This search order is the problem which is reliably addressed by locally inserting the configuration-specific item before the first occurence of the wrong item. This construction doesn't need particular parameters to find_library, allowing to transparently forward all arguments to find_library.

Guarding the first call with if(VCPKG_PREFER_SYSTEM_LIBS) doesn't help, because then we fall back to the default search path.

I would say people should use empty overlays in this case since it is the only way to not screw up the binary cache ...

I would say people should use empty overlays in this case since it is the only way to not screw up the binary cache ...

I tend to agree. Mixing system libraries with vcpkg invites undefined behaviour at runtime. But VCPKG_PREFER_SYSTEM_LIBS was merged nevertheless.
However, we can get rid of VCPKG_PREFER_SYSTEM_LIBS later, without changing the interface which is added in this PR.

@dg0yt Could you please handle the conflict?

@dg0yt Could you please handle the conflict?

Done. But this is a PR for discussion. Merge conflicts can be resolved after discussion.

Added two more functions.
The test port is gdal because it does have some dependening ports. Note that the even the curent version of FindGDAL.cmake uses GDAL_LIBRARY as a cache variable (filepath) and doesn't use select_library_configurations.

Mixing system libraries with vcpkg invites undefined behaviour at runtime. But VCPKG_PREFER_SYSTEM_LIBS was merged nevertheless.

I think this (and linked issue) has exposed fundamental problems with VCPKG_PREFER_SYSTEM_LIBS. This suggests to me that we should instead deprecate it, emit a warning, and instruct users that they should use empty overlay ports to correctly stub out system libraries.

Ping @ras0219-msft for review again.

@dg0yt Could you please handle the conflicts? Thank you!

Pinging @dg0yt for response. Is work still being done for this PR?

I'm going to resolve the merge conflicts soon. But this PR is really waiting for feedback from @ras0219-msft since December.

@dg0yt Could you please handle the conflicts? Thank you!

I tend to withdraw the proposed special functions.
However, the deprecation of VCPKG_PREFER_SYSTEM_LIBS could be merged via a separate PR.

If we consider defining VCPKG_BUILD_TYPE to release and then building in debug to be "UB", are these special functions still required? My understanding of the status quo (calling find_library() twice) is that the release library will be found and correctly used but the debug library will be one of {system copy, not found}. Then using that debug library is ambiguous and undefined for customers.

Adding these special functions helps to make this illegal scenario less ambiguous, but I'm not sure they're worth their weight in that scenario since there are no longer other policies they need to implement and regularize.

I would like to merge the VCPKG_PREFER_SYSTEM_LIBS deprecations you've put into this PR however. Would you be willing to shrink this PR to just those or open a different one?

I tend to withdraw the proposed special functions.
However, the deprecation of VCPKG_PREFER_SYSTEM_LIBS could be merged via a separate PR.

I would like to merge the VCPKG_PREFER_SYSTEM_LIBS deprecations you've put into this PR however. Would you be willing to shrink this PR to just those or open a different one?

-> #26449