[bug] CPS reader ignores a component's inline `configurations` map, so multi-config descriptors from `export(PACKAGE_INFO)` yield empty libraries

[mikirothman]

Describe the bug

Environment

• Conan version: 2.29.1 (mechanism also present on develop2 as of 2026-08)
• OS: Windows (generator-agnostic; the CPS parsing is platform-independent)
• Generator: CMakeConfigDeps (experimental CPS consumption)
• Producer: CMake 4.4 export(PACKAGE_INFO) / install(PACKAGE_INFO), multi-config
  generator (Ninja Multi-Config)

Summary

When a dependency's CPS descriptor stores per-configuration artifact locations in the
inline per-component configurations map (a valid CPS representation, and what CMake's
export(PACKAGE_INFO) emits for a multi-config build), Conan's CPS reader does not read it.
CPS.to_conan() therefore produces components with no libraries (libs/libdirs
empty), so a consumer fails to link (unresolved external / Cannot obtain 'location').

How to reproduce it

Reproduction

1. A multi-component package built with a multi-config generator that emits a CPS via
   export(PACKAGE_INFO) (e.g. consuming it as a Conan editable).
2. Consume with CMakeConfigDeps and self.cpp_info = CPS.load(cps_path).to_conan().
3. Inspect the generated dependency data: every component's *_LIBS_<CONFIG> and
   *_LIB_DIRS_<CONFIG> are empty; linking the consumer fails with unresolved externals.

Inspecting the descriptor shows the data is present, just inline:

{
  "components": {
    "MyLib": {
      "type": "dylib",
      "configurations": {
        "Debug":   { "link_location": ".../lib/Debug/MyLib.lib",   "location": ".../bin/Debug/MyLib.dll" },
        "Release": { "link_location": ".../lib/Release/MyLib.lib", "location": ".../bin/Release/MyLib.dll" }
      }
    }
  }
}

Consumer-side workaround

Hoist the active build type's inline config data to the component top level before
deserializing:

import json
from conan.cps.cps import CPS

with open(cps_path, encoding="utf-8") as fh:
    document = json.load(fh)
components = document.get("components", {})
if any("configurations" in c for c in components.values()):
    build_type = str(self.settings.build_type)
    for comp in components.values():
        cfg = (comp.get("configurations") or {}).get(build_type) or {}
        for key in ("location", "link_location", "link_libraries", "link_languages"):
            if not comp.get(key) and cfg.get(key):
                comp[key] = cfg[key]
    cpp_info = CPS.deserialize(document).to_conan()
else:
    cpp_info = CPS.load(cps_path).to_conan()

[AbrilRBS]

Hi @mikirothman thanks a lot for taking the time to report this.

This is an unfortunate decision (with respect to Conan) that CPS allows multiple configurations per file instead of being invariant:

Having mutli-configuration CPS files inside a Conan package is not expected, because Conan packages only ever represent 1 unique configuration (So there's no possibility of directly translating those files to the cpp_info model), but what can work is for the CPS file to be found directly by the build system, which can in turn understand the multiple configuration setup, as Conan was not involved in the process. This can be done by setting the cmake_find_mode property to CMakeConfigDeps to "none", (either in the recipe itself or the consumer) which will instruct CMakeConfigDeps to expose the CPS file inside the package folder to the consumers. See

conan/test/functional/toolchains/cmake/test_cps.py

Line 81 in 226b40a

# Lets consume directly with CPS

As for a way to simplify working with such CPS files when using the cpp_info model, after discussing with the team, we're looking into ways to have a best-effort heuristic for configuration overrides in components as shown in the linked PR #20295 alongside a way to force one using a new configuration attribute in the to_conan() call, but we still need to iterate over the idea.

The gist is that Conan could allow automatic detection of simple configurations based on build_type if they match (as that seems to be the usual variability key), ie CPS.load(cps_path).to_conan(self), which can also in turn be used to diferentiate language-dependant keys such as definitions, alongside a way to force a specific configuration using the second new configuration argument in case the configurations in your package do not match, ie CPS.load(cps_path).to_conan(configuration="release-shared")

I'm tentatively setting this for 2.33 so that we have enough time to check this, but feel free to try the related branch, feedback is always welcomed, and we will keep you updated once we know more :)