compiler.whitelist and compiler installation side-effects

[Ryan Schmidt]

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