[question] How to trigger a rebuild of all packages when updating the cross-compilation sysroot

[JKniep]

What is your question?

We are using a toolchain for cross-compiling as described in https://docs.conan.io/2/examples/cross_build/toolchain_packages.html, with the only notable difference that we have an additional conan package for the cross-compilation sysroot. We use it pretty much the same like the toolchain.

The toolchain and sysroot are referenced in our conan profile for the target as [tool_requires], and the compiler version of the toolchain is given in the settings:

[settings]
arch=armv7
...
compiler.version=7.3

[tool_requires]
arm-toolchain/13.2
arm-sysroot/13.2

When we receive an updated toolchain from our supplier, we update the arm-toolchain version in the profile (in the tool_requires section), and typically, we then also update the compiler.version. In this case, conan will generate a new package id because of the changed settings, and all conan packages will be rebuilt automatically with the new toolchain as soon as we use the new profile. But if we just update the sysroot (e.g. bump arm-sysroot to 14.0 in order to address vulnerabilities of system libs), conan will re-use existing packages that have been built against the older sysroot, which often doesn't work.

Now we could add a custom setting like sysroot.version (similar to the existing sdk_versions e.g. for iOS), and update it every time we update the sysroot. But I feel this not enough, because it may easily be forgotten to update sysroot.version. Would you rather recommend to somehow add a check for sysroot.version (maybe using profile.py?), or is there some way to reflect tool_requires in the package id? I know this is possible for configurations via tools.info.package_id:confs, but I didn't find any equivalent for tool_requires.

I am using conan 2.2.2 on Ubuntu 20.04.

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @JKniep

Thanks for your question.

There are indeed several mechanisms in Conan to make the tool_requires affect their consumers package_id.

• You have a default core.package_id:default_build_mode conf that you can set: https://docs.conan.io/2/reference/binary_model/custom_compatibility.html#global-default-package-id-modes This will apply to all tool_requires, not sure if this is what you are looking for, or it is too much.
• At a higher level, it is possible to affect the package_id of all packages that use a given configuration version, see the docs on https://docs.conan.io/2/reference/commands/config.html#conan-config-install-pkg (still experimental) including the core.package_id:config_mode

Now we could add a custom setting like sysroot.version

If you define for example the sysroot as a sub-setting of compiler, and you don't allow and empty value (by not providing null in the settings_user.yml) then it will complain if profiles don't define it. If this is not possible in general, because you have cases not using sysroot for the same compiler, then it is likely that a check in the profile.py plugin, conditioned to the logic you have to know which scenarios use a sysroot, and raising if the sub-setting is not defined, as you suggest, that could also be a good solution.

Please let me know if this helps.

[memsharded]

Uhm, this is interesting. It seems Conan already has the build_mode attribute in the codebase, same as https://docs.conan.io/2/reference/conanfile/attributes.html#reference-conanfile-attributes-package-id-modes, but for tool_requires, but it is not documented yet. You can try it, defining it in your sysroot recipe, and checking if it becomes part of the consumers of that package. Maybe it is time to make this public.

[JKniep]

Hi @memsharded, thanks, good to know that we have so many options. Probably we won't change the core.package_id:default_build_mode, because we have quite a lot of tools_requires which don't require a rebuild, but it's still good to know that this is possible. We'll need to experiment a bit with the core.package_id:config_mode to fully understand it, but from my point of view, you can already close this issue. Thank you.

[memsharded]

But the most important one, have you experimented with the build_mode = "xxxx" attribute in your toolchain recipe? That will allow to define the effect directly in the recipe you want.

As commented above, this is not documented, but it is there, so if working fine and with your feedback, it might be the necessary push to document it.

[JKniep]

Thanks, we'll try that, but it'll take some time. I'll update this ticket when we are ready.

[memsharded]

Sounds good. I'll close the ticket in the meantime, as it doesn't require any further action from us, but please re-open it or create a new ticket if you have any further feedback or question. Thanks!