Allow matching multiple packages by a pattern.

[sobczyk]

Changelog: Feature: Fix circular dependencies in complex tool_requires
Docs: https://github.com/conan-io/docs/pull/XXXX
Closes #17474

Profile contains:

[tool_requires]
gcc/15.0
mold/1.40

gcc conanfile is just an export-pkg, thus has no dependencies.
mold requires cmake to build (and gcc)

So we need to remove mold from cmake and gcc to fix cicular dependency.
I propose | as the character to split patterns:

[tool_requires]
gcc/15.0
!gcc/*|cmake/*:mold/1.40

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

[CLAassistant]

All committers have signed the CLA.

[memsharded]

Hi @sobczyk

Thanks for the contribution.

[tool_requires]
gcc/15.0
mold/1.40

This would need a bit more of clarification.
These [tool_requires] are added to the "host" profile, and then, they do not introduce any cyclic dependencies, because they are not injected to themselves.
Then, the recommendation is that the mold recipe list explicitly the self.tool_requires() it needs, as for tool-requires packages themselves it is much better to list them explicitly in recipes than a general injection at the profile level.

[sobczyk]

@memsharded I am lazy, I use -pr:a profile_name if I can.
I also do not want a lot to depend on build os, so build profile needs to be buildable too (requiring gcc)

When it comes to explicit tool requiremtns, it'd require from me to modify every conan index package to list a compiler and a linker, and it's much quicker to have it on profile level.

This patch would also help with disabling options for select list of packages ie. !not_here/*|here_neither/*:with_libpng=True - that's not possible currently

[memsharded]

I use -pr:a profile_name if I can.

Using -pr:a can be incorrect in different situations:

• When doing a build_type=Debug build, as it can put the tool-requires in Debug mode too, unwanted, can break or have side effects as much slower tools
• When doing any kind of sanitizing, similar reasons to Debug
• When doing cross-building

When it comes to explicit tool requiremtns, it'd require from me to modify every conan index package to list a compiler and a linker, and it's much quicker to have it on profile level.

This is not what I meant. The profile definition is good for "host" packages, regular libraries, etc, which is the vast majority of packages. Tool-requires are just a very small fraction of all packages. No need to modify every ConanCenter recipe to inject compilers or linkers, that is perfect as [tool_requires] in the "host" profile.

Then it is also possible to define [tool_requires] for the "build" context, in the build profile for tool-requires. But it doesn't need to be necessarily the same ones, and having just one or two explicit self.tool_requires() in some specific recipes help a lot to build things more robustly and without issues in all scenarios, including cross-building, Debug builds, etc.

I also do not want a lot to depend on build os, so build profile needs to be buildable too (requiring gcc)

You could define [tool_requires] for your gcc in the "build" profile, so it looks like the only recipe that would require some explicit self.tool_requires() would be mold

This patch would also help with disabling options for select list of packages ie. !not_here/|here_neither/:with_libpng=True - that's not possible currently

That is possible with the jinja template syntax and a for-loop over the patterns to disable.

In general we prefer to use "standard" language constructs, like Python or jinja2 ones than inventing our own wen possible.

I am not directly opposing to this change, but every new feature has an added complexity that compounds over time on future development, testing, documentation, maintenance, and user support, so we are very careful to understand the underlying use cases and needs. So far, this proposal seems motivated by a pattern that wouldn't be recommended in several different scenarios, or for other cases that have an alternative possible syntax (jinja2), and based on our experience I think it is very likely that this feature would have not considered rough/edge/corner cases.

[sobczyk]

Then it is also possible to define [tool_requires] for the "build" context, in the build profile for tool-requires. But it doesn't need to be necessarily the same ones, and having just one or two explicit self.tool_requires() in some specific recipes help a lot to build things more robustly and without issues in all scenarios, including cross-building, Debug builds, etc.

If host and build are the same (ie; we build for x86_64 linux), then it's easier to run -pr:b profile-release -pr:h profile-debug and then -pr:b profile-release -pr:h profile-release for final build.
Is there something I'm missing with tool requires?

I use qt and some glib, so the array of build tools have a pretty wide scope.
It'd be preferable that conan just pulled profile-release tools from my cache, rather than having a custom slimmed down build profile, but it'll have a lower chance of being cached.