-
Notifications
You must be signed in to change notification settings - Fork 252
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] generated settings.yml missing Macos.version "14.2", causes build failures #627
[bug] generated settings.yml missing Macos.version "14.2", causes build failures #627
Comments
Hi @garyo Thanks for your report.
I think this is not happening. Conan will not add
For these things it is better to use a |
You are right; my apologies. The |
Hi @garyo - thanks for providing more details. I just checked Otherwise it should be left undefined for Macos |
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 (?) 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 |
I'd like to clarify about this. Otherwise, the "canonical" Conan + CMake process would be more like:
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 |
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 |
Have added the missing versions to |
In that regard, please @garyo if you can provide us with a |
Sure - just clone https://github.com/garyo/cmake-conan-plugin-template and run ./build.sh in there, on a 14.2 (Sonoma) Mac.
|
Environment details
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
The text was updated successfully, but these errors were encountered: