On Sep 20, 2015, at 1:21 PM, René J.V. Bertin wrote: > On Sunday September 20 2015, Brandon Allbery wrote: > >> Because we can't provide any meaningful support if it's using a random >> compiler? > > That's what I meant with discourage rather than disallow. Someone savvy > enough to install a compiler outside of MacPorts (or to spend $$$ on > something like icc) can be expected to be able to deal with lack of support > (or at least understand that no support can be given)...
A user savvy enough can override configure.cc and configure.cxx on the command line when they install a port. >> I am aware that you want MacPorts to be a homebrewing system, not a >> repeatable builds system. I will note that the last such system discovered >> the hard way why, when you need to do support, you are better off with >> repeatable builds. > > Maybe, but again, a supported compiler that fits the criteria for > whitelisting shouldn't degrade the principle of repeatable builds. That > should be a clear self-evidence. And the llvm+clang ports are simply too > expensive in terms of disk space and build resources (when the bots are down > as apparently they still are) to be imposed. "Imposing" a MacPorts clang port, when a port cannot be built with a compiler provided by the user's Xcode, is the strategy we are currently using. > If required, find a way to provide a clang port that installs the latest > supported version for the host OS MacPorts base currently sets macports-clang-3.4 as the preferred version of MacPorts clang for use as a fallback. I think this was because at the time clang-3.5 and later would not build on older systems. I think the situation has improved since then but as we found clang-3.5 still needs libc++ which is not present by default on OS X 10.6 and earlier. Individual ports might still need other versions of clang. For example, it's possible that a port might blacklist macports-clang-3.4 for some reason. In that case, MacPorts will use a different compiler. > (and only upgrade that one when the bots are available...) Not at all something MacPorts supports. > and to depend on that in a compiler selection mechanism. Users would still > need to uninstall versions that are no longer needed, but at least they have > the choice then, without finding themselves reinstalling them > > But frankly, I don't see why it is OK to say "clang but not this or that > version or older than xyz" and not "macports-clang but not if older than > x.y". That is basically all I am looking for. I understand that's what you're looking for. MacPorts does not have support for it. The compiler_blacklist_versions portgroup lets you blacklist particular versions of the unit that MacPorts calls a "compiler". For MacPorts purposes, Xcode clang is a compiler, but different versions of Xcode install different versions of clang, hence the need for this portgroup so that particular versions of Xcode clang can be excluded. > At least blacklisting apparently works more or less as I'd expect. Is it at > least possible to blacklist specific macports-clang versions and version > ranges? > If so, one can probably write up a series conditional > compiler.blacklist-append statements that filter out the appropriate parts in > the compiler.whitelist setting. No, that is not possible today. For MacPorts purposes, each MacPorts port that provides a compiler is a separate compiler. So "macports-clang-3.4" is a different compiler from "macports-clang-3.5". _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
