[feature request][xbuild] Access environment variables from --profile:build and --profile:host simultaneously

[TheQwertiest]

Blocks #7026

Feature description:
Ability to access env variables from both --profile:build and --profile:host during build/test/etc steps.

Reasoning:
It seems that currently the only thing that is available from --profile:build during build/test/etc steps is settings_build, which contains only [settings] section of the profile. Env variables from host profile are appended to current environment and env vars from build profile are lost\not accessible.

To implement the full xbuild support for build systems, information about build compiler is required (which is usually passed via env variables in profile).

E.g. meson uses --native-file and --cross-file for xbuild configuration (which maps to conan's --profile:build and --profile:host respectively). The native file is used as a base profile during native compilation (when no cross file is supplied) and during xbuild it's used for things like code generation or compilation of build-time utils.

• I've read the CONTRIBUTING guide.

[jgsogo]

Hi!

Environment variables that are declared in the profiles for each context are intended to affect packages on that context only, the only ones that are propagated from build context to host are the ones declared by packages and the ones related to runtime.

I think that this feature request is tightly coupled to the Meson integration in Conan, probably it is better if we work together in that integration and then, when we know what is needed (maybe at that point we have a working branch in Conan) we can see if this is actually needed.

I'm not very familiar with Meson (I've never used it in a professional environment), but from your comment "To implement the full xbuild support for build systems, information about build compiler is required (which is usually passed via env variables in profile)." I would say that the compiler information about the compiler to use to build packages in the host context has to be declared in the env_vars inside the profile:host, those CC/CXX vars in the profile:build are declaring which compiler to use to build the packages in the build context.

If that compiler is a Conan package, declared as build_requires, then that package will declare in the package_info() method those CC/CXX environment variables and this information WILL be available as environment variables when running functions from recipes in the host context.

Let's see how we can work together on this, I can be wrong, and probably the documentation about cross-building with the new model in Conan is not very clear. And I need to understand better how Meson works. Maybe this is needed.

[TheQwertiest]

@jgsogo , I have a branch I'm working on, but it's still very early work in progress (it won't probably even compile at this point of time): develop...TheQwertiest:feature/meson_toolchain

Things of note: this would be a separate meson integration from the current one, since it will work very differently in regards of handling env vars and cross builds and it will require too much hacks to make it work with the current meson integration (and all that will be deprecated in conan 2.0 anyway). Thus I have cleaned up the interface and removed some legacy things.

So, regarding meson:

Meson allows to specify what target is targeting (pun not intended). E.g. a target might be a build tool (code generation for example), so it should be built in the native context only. Or a target might be a final shared library, so it should be built with the current host compiler (whether cross-compiler or native if it's not a cross build).

Docs about machine files: https://mesonbuild.com/Machine-files.html

The basic idea is that the build environment in meson is defined via machine files, so that all relevant build options are saved and it does not rely on the presence of environment variables.

There are two types of machine files: native and cross.
If cross file was specified, then meson identifies the build as a cross build and uses info from cross files for building all the cross targets.
native files define the build machine environment. It can always be specified regardless of it being the cross build or not. Let's say native file defines a compiler to use. Then in cross build it will be used only for native targets (build-time utils) and in non-cross build it will be used as a main compiler for all targets.

The new conan two-profile concept maps one-to-one to these machine files.
--profile:build describes a build machine environment and is equivalent of meson's native machine file.
--profile:host describes a target machine environment and is equivalent of meson's cross machine file.

PS: I've joined the conan's slack, so we can continue there if you want to have a real-time conversation =)

[Ericson2314]

Meson now uses the _FOR_BUILD suffix just like autotools, so one can provide both profiles at once doing that.

[TheQwertiest]

@Ericson2314 , I'm actually using this in my PR =)
But conan (if I understand correctly) is moving away from single-profile to double-profile model (similar to meson's native/cross).