[feature] make `[conf]` settings for the host context available in the build-context

[hlewin]

What is your suggestion?

Hello!

Cross-Compilers often need access to a target systems' sysroot-directory during their own compilation. The documentation seems to imply the conf setting tools.build:sysroot to set the right path for compilations - but that information is not available in the build-context.

Have you read the CONTRIBUTING guide?

• [x] I've read the CONTRIBUTING guide

[memsharded]

Hi @hlewin

Thanks for the suggestion.

I am trying to fully understand the flow of package creations, lets see if this is correct:

• There is some sysroot installed somehow (not with Conan) in the machine, e.g. in /some/path/mysysroot
• I want to create a Conan package that contains a cross-compiler.
• That cross-compiler itself, needs at the time of building itself access to that target sysroot. What exactly for? Do different sysroots result in different compilers? Or in other words, does the sysroot location should affect the package_id of the cross-compiler package?
• Does the cross-compiler needs to do something with that sysroot conf for regular usage of the cross-compiler once it has been built?

I think that a common approach is that users distribution such cross-compilers as Conan packages, they also put the sysroot inside the package itself, and then they define their self.conf_info.define_path("tools.build:sysroot", "my/own/pkg/path"), so it is injected automatically to the consumers packages that use that cross-compiler as tool_requires, so it is not necessary to worry about the tools.build:sysroot in the profiles.

[hlewin]

Hello!

That cross-compiler itself, needs at the time of building itself access to that target sysroot. What exactly for?

That is a question I would need to investigate more thoroughly if it makes a difference. For sure I know that things like libstdc++ and maybe the executable-stubs used by the compiler have dependencies on the sysroot. To quote the gcc install manual:

Cross-Compiler-Specific Options

--with-sysroot
--with-sysroot=dir
Tells GCC to consider dir as the root of a tree that contains (a subset of) the root filesystem of the target operating system. Target system headers, libraries and run-time object files will be searched for in there. More specifically, this acts as if --sysroot=dir was added to the default options of the built compiler.
...
This option affects the system root for the compiler used to build target libraries (which runs on the build system) and the compiler newly installed with make install; it does not affect the compiler which is used to build GCC itself.

If you specify the --with-native-system-header-dir=dirname option then the compiler will search that directory within dirname for native system headers rather than the default /usr/include.

Do different sysroots result in different compilers? Or in other words, does the sysroot location should affect the package_id of the cross-compiler package?

I'd say this may be the case. For sure there are some base packages whose versions may directly affect the compiler's system runtimes (like kernel headers, libc, ...). But as these generally affect binary compatibility between systems these need to be reflected in the settings object, like with version or vendor fields. In the case of linux systems you generally cannot just take something built on a bleeding-edge arch-linux system and run it on debian. Further than this the question gets a little philosophical: You can easily imagine eg a typical Debian sysroot with some common packages already installed. These may in fact influence which features the compiler-build will enable, ie you can construct a case where different sysroots will result in different compilers.

Does the cross-compiler needs to do something with that sysroot conf for regular usage of the cross-compiler once it has been built?

In the "normal" case where packages for the target system are compiled the config would be used to set the "--sysroot" flag as normal. This again may have an influence on binary compatibility of packages... To tell the (practical) truth: Our models of package's dependencies are typically incomplete. We do not generally list every system_requirement complete with versions. We have to take a "snapshot" and guarantee something like " This will run on Debian bullseye LTS if the system is fully upgraded" ie we generally do not put requirements like "glibc/[>2.1]" in our Conan recipes.

I think that a common approach is that users distribution such cross-compilers as Conan packages, they also put the sysroot inside the package itself, and then they define their self.conf_info.define_path("tools.build:sysroot", "my/own/pkg/path"), so it is injected automatically to the consumers packages that use that cross-compiler as tool_requires, so it is not necessary to worry about the tools.build:sysroot in the profiles.

Of course. But such a tool_requirement needs to be explicitly required by the cross-compiler to ensure it comes first in the dependency graph, I think. I couldn't help but rely on some naming convention based on settings_target to select a sysroot package, but I can already see this falling apart as it already needs some exceptions. This again has to do with the problem that "gcc" "in the build context" can mean "The gcc package used to build stuff for the building system" as well as "The gcc package used to compile stuff for the host system": In my understanding we cannot use package options any more to select the sysroot package. May be this worked because of a bug, but it seems with conan1 we could have a host profile that listed "gcc with sysroot package A" as tool_requirement and a build profile that listed "gcc without special sysroot" as tool_requirement. I remember this worked as long as there were prebuilt packages for the gccs (otherwise there was a conflict).

A possible solution would have been to use a "tools.build:sysroot_package" config or interpret the existing sysroot property in a special way if it has a value like "pkg:our_sysroot_package". We could of course just put everything into the settings-object, but: There already is a config for this and so we should embrace that: This is - in my understanding - the proposed way to set sysroots. So let's start with the simple case: We have a config settings that sets a sysroot and we want to build a compiler that works with it....