[bug] Tool requirement build fails with `-pr:b=<profile>`, but succeeds with `-pr=<profile>`

Environment Details

• Operating System+version: macOS 12.6 (Intel)
• Compiler+version: Apple clang version 14.0.0 (clang-1400.0.29.102)
• Conan version: 1.53.0
• Python version: 3.10.8

NOTE: This issue does not seem to be macOS-specific (see “Additional Notes”)

Steps to reproduce

• Create a conanfile.txt with glib as a tool requirement like so:

[tool_requires]
glib/2.74.1

• Create and install a profile for macOS called Macos like so:

[settings]
os=Macos
os_build=Macos
arch=x86_64
arch_build=x86_64
compiler=apple-clang
compiler.version=14.0
compiler.libcxx=libc++
build_type=Release

• Run conan install conanfile.txt --build=glib with -pr=Macos, observe that the build succeeds
• Run same conan install command, but replace -pr=Macos with -pr:b=Macos, observe that the build fails with the following output:

../src/meson.build:2070:2: ERROR: Dependency 'libpcre2-8' is required but not found.

Logs

meson-log.txt from failed build Output of conan install conanfile.txt -pr:b=Macos --build=glib (failed build) Output of conan install conanfile.txt -pr=Macos --build=glib (successful build)

Additional notes

• I do not believe this issue is specific to macOS – I see the same issue on our Ubuntu CI builders with a different profile.
• I can reproduce using any other profile as the host profile.
• So far, I have only been able to reproduce the issue with GLib as a tool requirement. I assumed this issue was not a bug in the recipe, since my understanding is that -pr=<profile> should be equivalent to -pr:b=<profile> -pr:h=<profile>. I apologize if that assumption was incorrect.
• My current workaround is to install with -pr=<profile> first to put the binary in my cache. I can then run conan install with -pr:b=<profile> and --build=missing to avoid building the package again.

[memsharded]

I am just trying to understand how this is not a bug in Conan itself. Regardless of the package, why would a tool requirement fail to build only when a build profile is specified explicitly. Both conan install cases are trying to build the exact same binary, as evidenced by the identical package IDs (7321193805ea53e6ab97f76e7ff364ed3daa18dc), yet one fails and the other doesn’t. What could the recipe possibly be doing to behave differently in these two scenarios?

I am not sure what you mean. Defining --profile:build=xxx is a opt-in that activates a completely different behavior in how Conan manages tool-requires. The dependency graph itself might be different, as transitive requires of tool_requires will no longer conflict with transitive requires of regular requires, because they will be in a different “context”, the “build” context. How the “build” context propagate information to its consumers in “host” context is also different from how “host” requires propagate information. So, activating the “build” profile can indeed produce a different behavior in Conan, and some recipes that can work without it might fail activating it, if recipes are not updated accordingly.

It doesn’t matter if the “build” profile is identical to the default one, or identical to the “host” profile either. Just by defining a --profile:build, the mere existence of the argument is an opt-in to a new way of expanding the dependency graph into “build” and “host” different contexts. If this argument is not provided, all packages are always in the same “host” context.

[memsharded]

Fixed in https://github.com/conan-io/conan/pull/12712 for 1.56