Conan-center-index: [question] cmake packages are dependent on compiler?

Created on 1 Sep 2020 · 3Comments · Source: conan-io/conan-center-index

I am trying to switch to the new cmake/*@ packages after the deprecation of cmake_installer/*@conan/stable packages.

I expected that I could just grab any pre-built package compatible with my build machine (os=Windows and arch=x86_64).

However, it seems that since the package_id is also affected by the compiler, I am forced to build from sources using my own compiler. The problem here is that my profile sets up my toolchain to cross-compile for an embedded device, and so the build will fail...

I'd like to know if this is intended behavior and what I should do in this case.

question

Source

GordonJess

Most helpful comment

The reason for keeping the compiler and build_type is that some people want to run cmake in debug mode and only have a specific mscrt installed.
Removing it from package_id would enable conflicts between debug and non-debug.

This thread shows the reasoning: https://github.com/conan-io/conan-center-index/pull/1783
See this comment: https://github.com/conan-io/conan-center-index/pull/1783#issuecomment-647428850

madebr on 1 Sep 2020

👍2

All 3 comments

I am working around it by forcing the settings of a pre-built package I found on conan-center

[settings]
cmake/*:compiler=Visual Studio
cmake/*:compiler.runtime=MT
cmake/*:compiler.version=14
cmake/*:build_type=Release

GordonJess on 1 Sep 2020

👍1

I've also noticed that most of the recent recipes intended to be mainly used as build_requirements (m4, pkgconf, cmake, libtool, ninja for example) have compiler, build_type, os and arch in their package id, instead of just arch_build and os_build.
It's really a waste of time to have to build those executables in debug mode or when using MinGW (even worse with MinGW, because it might fail), while we could just download pre build release binary of arch/os build plaform.