Blacklisting compiler versions or build numbers

[Ryan Schmidt]

Usually the reason why a port cannot build with clang is because of bugs in the port's software. In those cases we fix the code if we can and send it upstream; if we cannot, then we "compiler.blacklist clang". But sometimes it's because of a bug in clang that gets fixed in a later version of clang. In that case we need to be able to blacklist specific older versions of clang, or better yet specific older build numbers. We've even had the situation where sometimes a port that used to build with older clang no longer does with newer clang, so we need to be able to blacklist newer builds of clang as well, or possibly a range of build numbers.

Determining the compiler build number is not totally straightforward since it must be extracted from the output of `${configure.cc} -v`, and the regexp needed differs between [gcc and llvm-gcc] and clang. For example here's how I tried to do this recently for clang in cairo:

https://trac.macports.org/changeset/99503/trunk/dports/graphics/cairo/Portfile

But subtle differences between the output with different clang versions caused this to fail for Jeremy H who therefore switched it to check the Xcode version instead, since we already have an available $xcodeversion variable:

https://trac.macports.org/changeset/99782/trunk/dports/graphics/cairo/Portfile

But this is not sufficient because it is now possible, and I think more common than we realize, for users to upgrade Xcode but not upgrade the command line tools. This is because while the user is notified of available Xcode updates via the app store software update mechanism, they are not informed of available Xcode command line tools updates until they open Xcode itself, and many MacPorts users, who are not themselves software developers, would have no reason to ever open Xcode itself, so they never update their command line tools. Here's just the latest example of this happening and causing problems:

https://trac.macports.org/ticket/37123#comment:3

Jeremy H told me there were at least half a dozen other ports he could recall where $xcodeversion was used because it was convenient, but where using the clang build number would be more accurate.

One idea that occurs to me is modifying the compiler.blacklist syntax. For example:

"compiler.blacklist clang" would blacklist all versions of clang, as it does now.

"compiler.blacklist clang<318.0.61" would blacklist clang builds less than 318.0.61 (cairo might use this).

"compiler.blacklist clang>=421.11.66" would blacklist clang builds greater than or equal to 421.11.66 (mpich might use this).

"compiler.blacklist 421.11.66<=clang<444" would blacklist clang builds greater than or equal to 421.11.66 and less than 444 (mpich might use this, if whatever clang bug it hit is fixed in some hypothetical future clang build 444).

Does this seem like a workable solution? Any problems you can think of? Any alternative ideas for how to handle this? I think I could put together a proof of concept of the above in a portgroup, before we worry about putting it into base.