It seems that defining relative paths while exporting fixes it.

The generated CMake config.cmake file contains then:

# Compute the installation prefix relative to this file.
get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
if(_IMPORT_PREFIX STREQUAL "/")
  set(_IMPORT_PREFIX "")
endif()

# Create imported target pkg::pkg
add_library(pkg::pkg STATIC IMPORTED)

set_target_properties(pkg::pkg PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include"
)

# Load information for each installed configuration.
file(GLOB _cmake_config_files "${CMAKE_CURRENT_LIST_DIR}/pkgConfig-*.cmake")
foreach(_cmake_config_file IN LISTS _cmake_config_files)
  include("${_cmake_config_file}")
endforeach()
unset(_cmake_config_file)
unset(_cmake_config_files)

# Cleanup temporary variables.
set(_IMPORT_PREFIX)

There are a couple of challenges in this generated code:

• It assumes strictly 1 set of headers, but this might not be the case for Debug-Release packages with different headers (unusual but possible)
• It always define the target, not conditionally. So the different pkgConfig.cmake in different locations cannot be included from a common location to benefit from them
• The glob() happens at the current LIST_DIR

A possible approach could be:

• generate only the pkgConfig.cmake file, by CMakeConfigDeps
• This file does an include() of every individual -release/-debug.cmake config file. Most likely need parametrizable names. The include is using absolute paths to the different Conan cache locations
• The generated file will append new includes() with new paths for every new "conan install" new configuration
• Each one should define its own _IMPORT_PREFIX too, as the configuration specific code depends on it

This may be related.

One thing I've noticed relating to this, is that if I use cmake_find_mode="none" the project Config.cmake file won't be located if using the conan_provider.cmake.

I have to add the line:

    # Add conan toolchain so that a project in "none" type is found correctly.
    include(${_conan_generators_folder}/conan_toolchain.cmake)

I do know the BYPASS_PROVIDER option exists in CMake which is how we are finding non-conan managed dependencies, but the project in question is still conan managed, but not being found using that.

just before the second find_package call there for the config files in packages to be located at all. Otherwise find_package only looks in the generators folder from what I can tell.

One thing I've noticed relating to this, is that if I use cmake_find_mode="none" the project Config.cmake file won't be located if using the conan_provider.cmake.

yes, that is expected at the moment. The finding of in-package xxx-config.cmake depends at the moment on the CMakeToolchain generator. As the CMake-driven flow with the provider cannot pass the toolchain, as that needs to happen before CMake is called, and with the cmake-conan inversion of control where CMake is driving, that is not possible.

There is already ongoing work in the CMakeConfigDeps generator to generate a partial file conan_cmakedeps_paths.cmake with the necessary path definitions, not the whole toolchain, that can be included() to satisfy the needs of the cmake-conan flow. It might even be included automatically by the provider too, there is already a branch in cmake-conan repo for this.