Conan: Support for apple-clang 8.1

[sunxfancy]

There is a new version of clang in mac, please add supporting for it.

Invalid setting '8.1' is not a valid 'settings.compiler.version' value.

[memsharded]

Good, we will add it to the defaults settings.
Just in case, in the meantime you can add it to your settings.yml to keep working. Check: http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting

[sunxfancy]

Thanks for your reply, good solution.

[ghost]

I upvote this issue 👍

[memsharded]

No need to upvote @dimi309 , it is already in the 0.22 milestone :) :) :)

[ghost]

Sorry, just got a little excited :rofl:

[ilovezfs]

In the future it would be nice not to make compiler version checks fatal as it just leads to pointless failures downstream gets to chase.

[memsharded]

@ilovezfs the thing is that the input settings have to be validated against the predefined settings, otherwise each user will input non-standard settings and package hashes would never match. So the PR to homebrew failed because 8.1 is still not in the conan settings.yml file, we will add it for next release.

So, in my opinion, the inconvenience of having this checks in place is very small compared with the chaos that would happen if inputs settings are not validated.

[ilovezfs]

Given how long Xcode 8.3 has been available in beta, that's not particularly convincing.

[memsharded]

We add new versions to settings.yml as soon as they are requested, and release as soon as possible. We can't monitor everything, is the community that requests such inclusions.

[ilovezfs]

We can't monitor everything

This is why you should not hard code foreseeable failures to speculatively fix bugs that don't even exist yet. If every package in Homebrew required upstream to do a version bump whenever a new Xcode came out, we'd have chaos.

[lasote]

This is why you should not hard code foreseeable failures to speculatively fix bugs that don't even exist yet

@ilovezfs are you a conan user? Do you think a setting mismatch is speculative? or just guessing? Just asking...

[ghost]

How about a strict control up to the latest known version and then treating anything above that the same way as the latest one by default, allowing any increment?

The thing is, in some cases like Visual Studio (2017 is also not supported by the way, as far as I've been able to tell) it is easy to install the old toolchain in parallel and wait for a conan update. In cases like clang, which gets upgraded together with Xcode, the solution is less obvious and the issue can block work, which can be a problem if the developer has grown to count on conan.io.

I think there is an opportunity for conan to become more popular than the "hand made" projects constructed with automake, Xcode or Visual Studio. Its advantage is the package management, so removing the disadvantage of blocked builds can help a lot in that direction, by increasing trust.

[ghost]

Another idea might be being more permissive with versions locally but maintaining a strict control on conan.io, to avoid problems on the published packages. Maybe even having a parameter allowing users to control the strict/not strict aspect when they set up the conan server on their own infrastructure. Ok I'm stopping now. I'm getting ahead of myself 🐤

[ghost]

In any case these are just suggestions. I mean no offense. You guys are doing great work and you're making it available to us for free. (And, personally, I'm just working on some home-made projects for kicks, so I am not blocked or stressed or anything 😆 )

[memsharded]

This would also be a chaos. As we cannot know in advance the future versions, there is no way to provide both validation and hash-uniqueness. It is a fact, it is not possible to have both things simultaneously. You either balance towards having wrong hashes for package binaries or towards enforcing validation. We have clearly balanced towards validation, as we definitely don't want to have a mess on package binary hashes, that would render conan unusable.
So having from time to time to add latest versions to settings.yml is just a small inconvenience, and we do it as soon as it is requested. Definitely it doesn't block our users.

[ghost]

I understand. That works too and I can see the benefits. I was just
brainstorming. I guess we have to keep in mind that with Conan we have a
detailed registry of packages. Not just local builds where anything goes
since you can just erase everything and start over.

Le 4 avr. 2017 7:56 PM, "James" [e-mail] a écrit :

This would also be a chaos. As we cannot know in advance the future
versions, there is no way to provide both validation and hash-uniqueness.
It is a fact, it is not possible to have both things simultaneously. You
either balance towards having wrong hashes for package binaries or towards
enforcing validation. We have clearly balanced towards validation, as we
definitely don't want to have a mess on package binary hashes, that would
render conan unusable.
So having from time to time to add latest versions to settings.yml is just
a small inconvenience, and we do it as soon as it is requested. Definitely
it doesn't block our users.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/conan-io/conan/issues/1157#issuecomment-291581058,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA1an5kuI-z7V4Qma58MhZqYFSUDz9Qqks5rsoQ2gaJpZM4Ms5qf
.

[lasote]

It has been released in conan 0.22.0. Thanks!

[ilovezfs]

Thanks: https://github.com/Homebrew/homebrew-core/pull/12587.

[ghost]

Thanks!