[bug] generated settings.yml missing Macos.version "14.2", causes build failures

[garyo]

Environment details

• M1 Macbook Pro
• MacOS Sonoma 14.2.1
• conan 2.1.0
• python 3.11.5

Steps to reproduce

Run conan initially. It will generate a ~/.conan2/settings.yml with the latest version of Macos being "14.1", but the current version is actually 14.2. But it will put "os.version=14.2" into the default profile when you run "conan install". This causes conan to fail with "ERROR: Invalid setting '14.2' is not a valid 'settings.os.version' value."

Workaround is to manually add "14.2" to the OS versions listing in settings.yml.

Logs

No response

[memsharded]

Hi @garyo

Thanks for your report.

But it will put "os.version=14.2" into the default profile when you run "conan install"

I think this is not happening. Conan will not add os.version by default in the automatically detected profile for Macos. Could you please double check?

Workaround is to manually add "14.2" to the OS versions listing in settings.yml.

For these things it is better to use a settings_user.yml, easier to create and maintain

[garyo]

You are right; my apologies. The os.version=14.2 line is getting created in $PROJECT/build/conan_host_profile. That seems to be coming from my conan_provider.cmake which I got from https://github.com/conan-io/cmake-conan -- I believe that's the recommended cmake/conan integration. So I guess it's just a mismatch between that package (which detects the actual MacOS version, which in my case is indeed 14.2) and official conan. I'm not 100% sure how conan_provider.cmake works to detect the OS version; it might be getting it from cmake which is getting it from the OS.
I'm happy to add a settings_user.yml, but I expect others will run into this so perhaps I can report this wherever it actually ought to be fixed?

[jcar87]

Hi @garyo - thanks for providing more details.

I just checked cmake-conan and it should only add os.version to the profile if you have CMAKE_OSX_DEPLOYMENT_TARGET defined, is this the case for your project?

Otherwise it should be left undefined for Macos

[garyo]

I do, but it is defined to "11.0":

if(APPLE)
  set(CMAKE_OSX_DEPLOYMENT_TARGET
      "11.0"
      CACHE STRING "MacOS Deployment Target")
  ...

I suspect (?) cmake-conan runs before that is defined.

If you'd like a simple repro case, I'm using a template project I created a while ago. Check out https://github.com/garyo/cmake-conan-plugin-template and just run ./build.sh in there. It will show the error. That project does not set CMAKE_OSX_DEPLOYMENT_TARGET.

[memsharded]

I believe that's the recommended cmake/conan integration.

I'd like to clarify about this.
This is recommended if you have the need that your developers work only calling cmake, because for some reason they cannot call conan (like strong dependency on just working from CLion IDE, without even touching a terminal).

Otherwise, the "canonical" Conan + CMake process would be more like:

$ conan install ... 
$ cmake --preset conan-default

Separating the conan installation of dependencies from the actual cmake build. This is better in many regards, more control, more visibility, developers taking ownership of failures and identifying fixes and improvements instead of just "the build is broken" complaining to someone else...

[garyo]

I believe that's the recommended cmake/conan integration.

I'd like to clarify about this. This is recommended if you have the need that your developers work only calling cmake, because for some reason they cannot call conan (like strong dependency on just working from CLion IDE, without even touching a terminal).

Otherwise, the "canonical" Conan + CMake process would be more like:

$ conan install ... 
$ cmake --preset conan-default

Separating the conan installation of dependencies from the actual cmake build. This is better in many regards, more control, more visibility, developers taking ownership of failures and identifying fixes and improvements instead of just "the build is broken" complaining to someone else...

Yeah, I get that. I figured it's just one more hurdle for someone using/building the project to have to learn & understand, when they're more-or-less used to calling cmake. Especially since the conan cmd line invocation is usually fairly long and specific; you pretty much have to wrap it up into a shell script as I did in that sample project, unless you can get cmake to call it.

In the sample project I linked above, I did provide a shell script that invokes conan manually first (see build-conan-ninja.sh), and that does not suffer from the bug I'm reporting here -- it does not create a file conan_host_profile and the build completes normally. To be honest, I don't fully understand all the interactions here between conan, cmake and the integration file, so if you folks say there is nothing to be fixed, I'll just keep my settings_user.yml.

[memsharded]

I figured it's just one more hurdle for someone using/building the project to have to learn & understand, when they're more-or-less used to calling cmake.

That is the doubled edged sword. If they are using a tool like Conan they have to learn and understand that tool, in the same way the have to understand git, understand the IDE, understand linters or sanitizers errors, etc. Otherwise, trying to just isolate devs from a tool means they will get blocked when some small detail is not working, and they will just rely on someone else, maybe you, the typical "build-engineer" or "devops manager" with the "build is broken, please fix it", creating bottlenecks. So it is kind of appealing in the short term, but this is not great in mid term.

FYI, the 14.2 is going to be added to the default settings in conan-io/conan#15859, for next 2.2 release.

Still, it would be great to understand why cmake-conan integration is adding that, because it is not expected that adding os.version is the default, only when users opt-in via the CMAKE_OSX_DEPLOYMENT_TARGET, so that might be a but in cmake-conan we would like to check.

[jcar87]

Have added the missing versions to settings.yml, however I'm reopening the issue and transferring to cmake-conan to better investigate the behaviour

[memsharded]

In that regard, please @garyo if you can provide us with a CMakeLists.txt that results in os.version=14.2 definition while executing the cmake with the conan_provider.cmake, that would be great to understand the potential issue. Thanks!

[garyo]

Sure - just clone https://github.com/garyo/cmake-conan-plugin-template and run ./build.sh in there, on a 14.2 (Sonoma) Mac.

% ./build.sh                          
############ Configuring with conan and cmake (using conan-cmake integration) ########
Preset CMake variables:

  CMAKE_BUILD_TYPE="Release"
  CMAKE_PROJECT_TOP_LEVEL_INCLUDES="conan_provider.cmake"

-- The CXX compiler identification is AppleClang 15.0.0.15000309
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- CMake-Conan: first find_package() found. Installing dependencies with Conan
-- CMake-Conan: Checking if a default profile exists
/Users/garyo/.conan2/profiles/default
-- CMake-Conan: cmake_system_name=Darwin
-- CMake-Conan: cmake_osx_deployment_target=14.2
-- CMake-Conan: cmake_system_processor=armv8
-- CMake-Conan: CMake compiler=AppleClang
-- CMake-Conan: CMake compiler version=15.0.0.15000309
-- CMake-Conan: [settings] compiler=apple-clang
-- CMake-Conan: [settings] compiler.version=15
CMake Warning at conan_provider.cmake:292 (message):
  CMake-Conan: The C compiler is not defined.  Please define CMAKE_C_COMPILER
  or enable the C language.
Call Stack (most recent call first):
  conan_provider.cmake:371 (append_compiler_executables_configuration)
  conan_provider.cmake:518 (detect_host_profile)
  CMakeLists.txt:10 (find_package)


-- CMake-Conan: Creating profile /tmp/cmake-conan-plugin-template/build/Release/conan_host_profile
-- CMake-Conan: Profile: 
[settings]
arch=armv8
os=Macos
os.version=14.2
compiler=apple-clang
compiler.version=15
compiler.libcxx=libc++
build_type=Release
[conf]
tools.cmake.cmaketoolchain:generator=Unix Makefiles

-- CMake-Conan: Installing single configuration Release
-- CMake-Conan: conan install /tmp/cmake-conan-plugin-template -of=/tmp/cmake-conan-plugin-template/build/Release/conan --profile:host=default;--profile:host=/tmp/cmake-conan-plugin-template/build/Release/conan_host_profile;--profile:build=default;--build=missing
ERROR: Invalid setting '14.2' is not a valid 'settings.os.version' value.
Possible values are ['10.6', '10.7', '10.8', '10.9', '10.10', '10.11', '10.12', '10.13', '10.14', '10.15', '11.0', '11.1', '11.2', '11.3', '11.4', '11.5', '11.6', '11.7', '12.0', '12.1', '12.2', '12.3', '12.4', '12.5', '12.6', '12.7', '13.0', '13.1', '13.2', '13.3', '13.4', '13.5', '13.6', '14.0', '14.1']
Read "http://docs.conan.io/2/knowledge/faq.html#error-invalid-setting"
CMake Error at conan_provider.cmake:432 (message):
  Conan install failed='1'
Call Stack (most recent call first):
  conan_provider.cmake:539 (conan_install)
  CMakeLists.txt:10 (find_package)


CMake Warning at CMakeLists.txt:10 (find_package):
  By not providing "Findspdlog.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "spdlog", but
  CMake did not find one.

  Could not find a package configuration file provided by "spdlog" with any
  of the following names:

    spdlogConfig.cmake
    spdlog-config.cmake

  Add the installation prefix of "spdlog" to CMAKE_PREFIX_PATH or set
  "spdlog_DIR" to a directory containing one of the above files.  If "spdlog"
  provides a separate development package or SDK, be sure it has been
  installed.


-- Configuring incomplete, errors occurred!
% cat build/Release/conan_host_profile 
[settings]
arch=armv8
os=Macos
os.version=14.2
compiler=apple-clang
compiler.version=15
compiler.libcxx=libc++
build_type=Release
[conf]
tools.cmake.cmaketoolchain:generator=Unix Makefiles