[feature] Allow profiles to accept negated qualifiers

[System-Arch]

Currently, from what I can tell, the only case in which a profile qualifier can be negated is if the qualifier is "&" as documented here: https://docs.conan.io/en/latest/devtools/build_requires.html?highlight=tool_requires#declaring-tool-requirements

I have a use case where it would be useful to be able to apply a tool_requirement to every tool except itself. Here's what I'm trying to do:

[settings]
os=Macos
arch=x86_64
compiler=apple-clang
compiler.version=14
compiler.libcxx=libc++
build_type=Release
[options]
cmake*:bootstrap=True
[tool_requires]
cmake*!:cmake/3.24.2

My current workaround is to explicitly add a dependency on each tool I am building that requires cmake, for example:

[settings]
os=Macos
arch=x86_64
compiler=apple-clang
compiler.version=14
compiler.libcxx=libc++
build_type=Release
[options]
cmake*:bootstrap=True
[tool_requires]
ninja*:cmake/3.24.2

One other observation is that while the documentation cited above shows a space character after the colon separating the qualifier from the requirement, my experience is that these statements only function (at least in Conan 2.0.0-beta4) if the space is removed.

• I've read the CONTRIBUTING guide.

[memsharded]

Hi @System-Arch

I think this is automatically addressed by the 2 profiles approach:

• You only add [tool_requires] to cmake/3.23 for example, to the "host" profile
• This applies automatically that to all packages in the "host" context
• cmake package is automatically in the "build" context, so it is not affected by the above [tool_requires]

Could you please check that? Thanks!

[memsharded]

Also, it seems that Conan 2.0 already implemented negated profile tool_requires:

[tool_requires]
tool1/1.0
!tool1*:tool2/1.0

[System-Arch]

I think this is automatically addressed by the 2 profiles approach:

• You only add [tool_requires] to cmake/3.23 for example, to the "host" profile
• This applies automatically that to all packages in the "host" context
• cmake package is automatically in the "build" context, so it is not affected by the above [tool_requires]

Could you please check that? Thanks!

Hi @memsharded

I am nominally using the two profiles approach, but in this use case, where I am bootstrapping the tools themselves, I am using the "tools" profile for both "build" and "host". The feature I am seeking and that you point out below already exists, nearly covers my use case. I have one complication that is leading to a graph loop.. I am trying to start the bootstrapping process by building openssl, which cmake depends on at build time. openssl does not use cmake to build, so ultimately what I seek is something like:

[tool_requires]
!cmake* and !openssl*:cmake/3.24.2

Any thoughts on how this might be achieved?

Also, it seems that Conan 2.0 already implemented negated profile tool_requires:

[tool_requires]
tool1/1.0
!tool1*:tool2/1.0

Indeed. That is excellent. Hopefully this will be documented as a supported feature.

[memsharded]

This is the code that does the matching in 2.0:

            if ref_matches(ref, pattern, is_consumer=conanfile._conan_is_consumer):
                for tool_require in tool_requires:  # Do the override
                    if str(tool_require) == str(ref):  # FIXME: Ugly str comparison
                        continue  # avoid self-loop of build-requires in build context

So apparently, it would be possible, because if the passed tool_requires matches itself, it will be automatically discarded to avoid infinite self-loop (while using another version of yourself it is a supported case, to implement bootstrapping of tools)

Though I think that for the build context, I'd probably try to be more explicit, and add the tool_requires directly in recipes, and not in the profiles. Typically the build context contains way less packages, so it is easier to maintain.

[System-Arch]

Hi @memsharded, @prince-chrismc,

Indeed--you are correct. Simply using:

[options]
cmake*:bootstrap=True
[tool_requires]
!openssl*:cmake/3.24.2

lets me achieve my goal of being able to bootstrap build tools on Mac and Linux using off-the-shelf CCI recipes with Conan 2.0. In summary, I can start by building openssl, which does not require cmake, then build cmake (using the boostrap option), which does require openssl, and then build any other tool that requires cmake (e.g., zlib), all without having a pre-installed version of CMake,

In full disclosure, this workflow is dependent on my pending pull requests in Conan Center Index:
conan-io/conan-center-index#14066 [openssl]
conan-io/conan-center-index#13739 [cmake]
conan-io/conan-center-index#13706 [zlib]

Alternatively, we could start adding tool_requires statements to recipes like zlib to indicate that they depend on CMake to build or one could even imagine that using CMakeToolchain or cmake_layout would automatically add a tool_requires on cmake. The issue with this approaches is that one has to specify a specific version of cmake, which makes maintenance potentially more challenging. Using the build_profile to specify the tool_requires of cmake provides a single truth that can be used for updating the entire tool chain.

Thanks,

[System-Arch]

Closing as the existing behavior meets my needs now that I know the correct syntax to use.