Blacklisting compiler versions or build numbers

[Rainer Müller]

On 2012-11-25 17:48, Jeremy Huddleston Sequoia wrote:
> # All clang versions blacklisted
> compiler.blacklist-append clang
> 
> # clang < 308 blacklisted:
> compiler.blacklist-append {clang < 308}
> 
> # clang >= 421.11.66 and < 444 blacklisted
> compiler.blacklist-append {clang >= 421.11.16 < 444}

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

b) Add {clang >= 421 < 422} to the blacklist

This would be an optimistic blacklist entry assuming that the problem
will be fixed in the next release of clang. If it is not fixed, we will
get build errors, but it may lead to failed builds at end-users not
willing to report the error and giving up with frustration.

What would be the preferred option?


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

Rainer