Blacklisting compiler versions or build numbers

[Ryan Schmidt]

On Dec 8, 2012, at 21:14, Rainer Müller wrote:
> What should I specify in case I don't know yet when this will be fixed?
> 
> Assume a port is broken with the current build of clang 421.11.66, but
> it is not clear in which build number this will be fixed or, if the
> developers say something like "fixed in next Xcode version", which build
> number of clang this will actually be.
> 
> So I would have the options:
> 
> a) Add {clang >= 421} to the blacklist
> 
> This blacklist entry prevents any newer build of clang to be used.

This is what I would use.

> When
> eventually someone is brave enough to remove the blacklist entry we can
> probably not trace back which release of clang actually fixed the
> problem and might just add the most recent build number as upper bound.

If clang >= 421 fails to build the port, then the blacklist entry should not be removed unless the source gets modified to work around the clang bug.

If a later version of clang e.g. 555 eventually does compile the port correctly, then amend the blacklist with that information.

compiler.blacklist-append {clang >= 421 < 555}


> By the way it would be nice to have a shorter syntax for matching a
> specific major version as used in option b). Using {clang == 421} would
> be wrong as that only matches 421.0.0 exactly. Although I can't think of
> a good operator for this at the moment...

The portgroup doesn't parse the operators itself; it hands them to expr.

http://wiki.tcl.tk/583

We could change that if need be, but I have no knowledge of Apple's clang build numbering strategy so specific numbers have no particular meaning to me. I cannot guess at the meaning of an increase in any of the digits of the build number. Therefore I recommend just specifying it as best you can and refine it as further information becomes available.

The problem this portgroup was trying to solve is ports that indiscriminately blacklist clang, when a particular problem is only caused by certain older versions. This was happening frequently.

Less frequently we have the case you mention, where a newer version of clang causes a problem. In this case we'll just have to test again with newer versions of Apple clang and refine the blacklist when we find a newer version that works again.