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

[Ryan Schmidt]

On Apr 29, 2016, at 3:20 AM, René J.V. Bertin wrote:

> On Thursday April 28 2016 21:37:53 Ryan Schmidt wrote:
> 
>>> 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?

I looked at the version number of the llvm-3.7 port and noted it was 3.7.1, which looks like a stable version number.
I looked at the version number of the llvm-3.8 port and noted it was 3.8-r262722_1, which looks like a development version number.

> 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.

I concur, that's how Jeremy has historically handled it. And in r146341 he turned it off for llvm-3.8, noting that he did so because it is now a stable release. So I guess llvm-3.8 is already considered stable.

> 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?

To which compiler selection mechanism are you referring?

I was referring to the process of a developer deciding what variant version to enable by default, when a port offers multiple version variants.


> 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.

I guess I really don't understand what issue you're trying to work around or why. I don't see why the existing methods we've used to handle this situation, as I've described, aren't satisfactory to you.