Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] CMakeToolchain: CMAKE_SYSTEM_PROCESSOR and CMAKE_SYSTEM_NAME not set properly #14126

Closed
nicosmd opened this issue Jun 19, 2023 · 4 comments · Fixed by #14556
Closed

[bug] CMakeToolchain: CMAKE_SYSTEM_PROCESSOR and CMAKE_SYSTEM_NAME not set properly #14126

nicosmd opened this issue Jun 19, 2023 · 4 comments · Fixed by #14556
Assignees
Milestone

Comments

@nicosmd
Copy link
Contributor

nicosmd commented Jun 19, 2023

Environment details

  • Operating System+version: Ubuntu 20.04
  • Compiler+version: gcc 10.2
  • Conan version: 2.0.6
  • Python version: 3.10.9

Steps to reproduce

Hey,

I encountered the issue described in this issue: #13914

When I use a toolchain package with a package_info method looking like

  def package_info(self):
      self.buildenv_info.append_path("PATH", join(self.package_folder, "bin"))

      vars = {
          "CC": "aarch64-linux-gnu-gcc",
          "CXX": "aarch64-linux-gnu-g++",
          "LD": "aarch64-linux-gnu-ld",
          "AS": "aarch64-linux-gnu-as",
          "AR": "aarch64-linux-gnu-ar",
          "STRIP": "aarch64-linux-gnu-strip",
          "RANDLIB": "aarch64-linux-gnu-randlib",
          "NM": "aarch64-linux-gnu-nm",
      }

      for env_var, value in vars.items():
          app_path = join(self.package_folder, "bin", f"{value}")
          self.buildenv_info.define(env_var, app_path)

      self.conf_info.define("tools.cmake.cmaketoolchain:system_name", "Linux")
      self.conf_info.define("tools.cmake.cmaketoolchain:system_processor", "aarch64")
      self.conf_info.define("tools.build:compiler_executables", {"c": vars["CC"], "cpp": vars["CXX"]})

using a profile similar to

[settings]
arch=armv8
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=10.2
os=Linux

[tool_requires]
toolchain/1.0
sysroot/1.0

the conan_toolchain.cmake contains

...
# Cross building
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)

, which is as expected.

But as far as I add

[conf]
tools.cmake.cmaketoolchain:user_toolchain = ['{{ os.path.join(profile_dir, "extras", "toolchain_extras.cmake") }}']

to the profile, both variables aren't set anymore in the conan_toolchain.cmake.
The toolchain_extras.cmake basically contains only some project specific variables, nothing special.

In both cases

...
set(CMAKE_C_COMPILER "aarch64-linux-gnu-gcc")
set(CMAKE_CXX_COMPILER "aarch64-linux-gnu-g++")

is set properly.

What could I do wrong?

Thanks!

Logs

No response

@memsharded
Copy link
Member

Hi @nicosmd

The current definition of CMAKE_SYSTEM_NAME is:

 def _get_cross_build(self):
        user_toolchain = self._conanfile.conf.get("tools.cmake.cmaketoolchain:user_toolchain")
        if user_toolchain is not None:
            return None, None, None  # Will be provided by user_toolchain
        system_name = self._conanfile.conf.get("tools.cmake.cmaketoolchain:system_name")


def context(self):
        system_name, system_version, system_processor = self._get_cross_build()
        ...
        return {"toolset": toolset,
                "generator_platform": generator_platform,
                "cmake_system_name": system_name,

So it seems this is by design. Once the user_toolchain is provided, it is expected to control those variables directly to avoid having to define extra confs in Conan maybe, in the original PR: https://github.com/conan-io/conan/pull/10856/files

But it is true that if the tools.cmake.cmaketoolchain:system_name is defined, why not just use it? I'll bring the issue to the team to discuss the current behavior and if it can be changed.

@memsharded memsharded added this to the 2.0.8 milestone Jun 19, 2023
@memsharded memsharded modified the milestones: 2.0.8, 2.0.9 Jul 11, 2023
@memsharded memsharded modified the milestones: 2.0.9, 2.0.10 Jul 19, 2023
@memsharded
Copy link
Member

It seems that it makes sense to listen to system_name in all cases, even if user_toolchain is defined, lets fix it.

@fschoenm
Copy link

Lucky that I found this ticket. I just ran into the same issue when experimenting with packaging Clang (see #14542). In that case, the same package can be used for (cross)compiling to different target architectures and because of that, an included toolchain file cannot even know the correct system processor/name.

@memsharded
Copy link
Member

Here goes the PR for it #14556, for next 2.0.10

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants