automatic choice of a default +llvmXY variant via selected compiler?

[René J.V. Bertin]

On Thursday April 28 2016 21:37:53 Ryan Schmidt wrote:

Hi,

>> I would think that an adaptive mechanism to determine a default variant isn't incompatible with reproducible builds (or at least an accepted/able exception) because the selected variant will still build the same everywhere.
>> If so, is the definitive choice of compiler known sufficiently early to use it for defining a default variant, and/or is there already something in place to do this? I don't have access to my Mac right now so I cannot just check for myself.
>
>When multiple version variants are available, we usually suggest you default to the latest stable version. Right now that's llvm-3.7.

How do you define stable in this case? For clang/llvm I've been watching the assertions variant, thinking it'd be turned off by default once a version reaches sufficient stability, is that not correct? It's been off for a while for llvm-3.8 now, and if I'm not mistaken 3.8 has the big advantage of being a lot smaller.

Either way, I don't think the compiler selection mechanism itself follows this guideline. If it hasn't been updated in svn I presume it still takes the first (lowest) version that passes the selection criteria?

I've been attempting to work around the whole issue; I've added a (non-default) +system variant to the dependent port in question (KF5 KDevelop) which basically means "use whatever llvm-config you can find" and ripped the (smallish) plugin that contains the actual libclang dependency into its own subport. That wasn't too difficult with a patch of the build system because the plugin can be built in isolation; sadly upstream don't see the point incorporating it.

R.