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. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
