[bug] build requirement packages should have the possibility to influence the package id

[a4z]

Say you compile for Android, using the r21d NDK as a build requirement
(I am assuming the 2 profile build, -pr:b and -pr:h is used)
and say you using something like this conan-io/conan-center-index#3004 to compile for Android

the NDK is always a build for the build machine, but version r21d will deliver a different result than future or past versions, and builds from different NDKs should not be mixed together.

Today I have no possibility to say, for example, give me openssl build for Android ArmV8 using the r21d in a query.
But this possibility should exists, because otherwise, when there are builds with multiple NDKs of the same package are available, I think there will be an extraordinary bad user experience.

Environment Details (include every applicable attribute)

• Operating System+version: any
• Compiler+version: any
• Conan version: 1.30.1
• Python version: 3.8.5

Steps to reproduce (Include if Applicable)

use a build requirement like the NDK and build the same software, but change the build requirement.
I think they always end up with the same package id.

[memsharded]

yes, this should totally be doable.

The main blocker for this feature is that for making the build-requires affect the package-id, the build-requires must be always evaluated, recipes fetched and their info gathered, so the consumers package-id can be computed as a function of it. But at the moment the build requires are exclusively evaluated and fetched when it is necessary to build from sources, and that cannot be easily changed without breaking. So our proposal for Conan 2.0 will be:

• The graph is always completely evaluated, including build-requires.
• Build requires can be part of the package-id, with similar rules (semver-mode, minor-mode, etc) as the regular requires.
• What will be optimized is downloading and installing the binary of the build-requires, but the recipe will always be fetched (necessary to evaluate the package-ids)

This is a major change in the way the graph is evaluated, we need to make sure this doesn't have any unexpected rough edges, for example, when cross-building and installing later in the host environment, so we will run this proposal through the Tribe 2.0.

[a4z]

I think I am not in the Tribe, even if I think I applied, but when I can help you with this, please let me know.
because when the next Android NDK is released, I might be in real troubles ;-)

[memsharded]

I think I am not in the Tribe, even if I think I applied, but when I can help you with this, please let me know.
because when the next Android NDK is released, I might be in real troubles ;-)

The Tribe 2.0 has not been launched yet, it was delayed because of some internal things, but it will be launched soon, we will update about it.

[a4z]

just chatted with @theodelrieu and we noticed that this issue and that #2974 might be related in some sense

[memsharded]

Last blog post of Conan 1.32 describes a workaround that might be used to make the build_requires affect the package_id: https://blog.conan.io/2020/12/14/New-conan-release-1-32.html. Is this what has triggered that chat?

[theodelrieu]

@memsharded

Is this what has triggered that chat?

No, I asked Harald some advices on dual profile cross-building, which put light on some "toolchain" recipes issues.

[a4z]

@memsharded , can you please help me

you mean I add something like this https://docs.conan.io/en/latest/reference/conanfile/other.html?highlight=python_requires
so basically something like python_requires = "android-ndk/r21d@"

but how to do that in the package_id of android-ndk/r21d@ for an other package (that one that is using it for building)?

[theodelrieu]

@a4z The caveat here is you have to add that python_requires in every requirement's recipe.

[a4z]

but that is not a workaround, that is just a bad idea...

[theodelrieu]

It is mentioned in the 1.32 blog post:

Again, it seems good to be true, so lets highlight the biggest problem. If you leverage your build_requires via profiles, this won’t work for you at all. It’s unfortunate, because that describes a lot of use-cases for build_requires, but not all. In any case, we think some users will be able to use this strategy, so we wanted to announce the discover here.

[a4z]

indeed, thanks for the info Théo.

Maybe that's why my brain rejected to process that, since it is not very useful...

[memsharded]

This has been implemented in 2.0, and released in betas:

• Conan 2.0 always contain tool_requires in the graph (the recipes, not necessarily the binaries)
• By default, they don't affect the consumers binaries, but there is a conf to define how they should affect (which mode: minor, major, etc)

[a4z]

This sounds very promising, thanks a lot!

Can't await to do real work with Conan 2.0, even if I fear daywork will be stuck on 1.x for quite a while