[question] Toolchain cross building integration

• Conan version: 1.47.0
• OS: Ubuntu 20.04
• python 3.6

I had a similar question one year ago #8922, so I am trying again to integrate conan deeper into our building system.

I have created a conan package called LinaroArm64Toolchain and a profile linaro-aarch64-gcc10.2-linux5.4_release.txt with the following content.

include(default)
[settings]
os=Linux
arch=armv8
compiler=gcc
compiler.version=10
compiler.libcxx=libstdc++11
build_type=Release

[tool_requires]
linaro-aarch64/10.2.1

[options]
[env]

• Now I can cross build packages with the profile without any issue, and I can see variables such as CC, CXX are populated correctly without any issue.

conan create . hsuan/test --profile:host=./profiles/linaro-aarch64-gcc10.2-linux5.4_release.txt --profile:build=./profiles/linux-x86_x64-build-default.txt 

What I would like to achieve next is building a project with toolchain integrated with conan using CMakeToolchain, for example:

conan install ../conanfile.txt --profile:host=./profiles/linaro-aarch64-gcc10.2-linux5.4_release.txt --profile:build=./profiles/linux-x86_x64-build-default.txt 
cmake -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake ..
make

However, it seems this still doesn’t work, as env_info I defined in LinaroArm64Toolchain can’t be seen conan_toolchain.cmake, those 2 are correct set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR armv8)

But not CONAN_CMAKE_SYSROOT nor CXX, CC.

Same as 1 year ago, this does work with virtualenv

conan install ../conanfile.txt --profile:host=./profiles/linaro-aarch64-gcc10.2-linux5.4_release.txt --profile:build=./profiles/linux-x86_x64-build-default.txt 
source activate.sh
cmake  ..
make

I wonder if there are any alternatives now? for example, if it is possible to customize conan_toolchain.cmake in LinaroArm64Toolchain ? So we can add what ever we need? Or is there any way we can create a toolchain file defined in LinaroArm64Toolchain when we call conan install without CMakeToolchain?

Many thanks

[memsharded]

Hi @ericriff

Yes, one of the issues we have open to keep working on this is https://github.com/conan-io/conan/issues/10317 (for beta.1)

Yes, the new approach is using self.buildenv_info, because it has several advantages:

• It explicitly differentiate “build” time and “run” time environments
• It is more explicit: self.buildenv_info.prepend_path("PATH", ....), both for vars that are path-like, and also the intended action
• It doesn’t inject it in memory (python process memory), but always via environment scripts files, so it is easier to debug and reproduce on the developer side.

[ericriff]

We package a toolchain with conan and then we expose it using env variables declared on the recipe, like this:

    def package_info(self):
        bin_path = os.path.join(self.package_folder, "bin")

        self.env_info.PATH.append(bin_path)
        self.env_info.CC = f"{self._target}-gcc"
        self.env_info.CXX = f"{self._target}-g++"
        self.env_info.CPP = f"{self._target}-gcc -E"
        self.env_info.AS = f"{self._target}-as"
        self.env_info.LD = f"{self._target}-ld"
        self.env_info.GDB = f"{self._target}-gdb"
        self.env_info.STRIP = f"{self._target}-strip"
        self.env_info.RANLIB = f"{self._target}-ranlib"
        self.env_info.OBJCOPY = f"{self._target}-objcopy"
        self.env_info.OBJDUMP = f"{self._target}-objdump"
        self.env_info.READELF = f"{self._target}-readelf"
        self.env_info.AR = f"{self._target}-ar"
        self.env_info.NM = f"{self._target}-nm"
        self.env_info.M4 = "m4"
        self.env_info.BIN_PATH = bin_path
        self.env_info.LC_ALL = "C"

        self.env_info.CFLAGS = cFlags
        self.env_info.CPPFLAGS = cppFlags
        self.env_info.CXXFLAGS = cxxFlags
        self.env_info.LDFLAGS = ldFlags

Is env_info deprecated in favor of buildinfo and runinfo @memsharded ?