compiler-blacklist-versions: simplify clang blacklisting by associating Apple clang versions with macports-clang versions

[kencu (Ken)]

Long title, apologies.

It might be helpful if we could find an association between Apple clang releases and macports-clang-N versions such that blacklisting a given version of clang, such as {clang < 800} would automatically also blacklist macports-clang-3.8 and below (or whichever version best correlates).

[ryandesign (Ryan Carsten Schmidt)]

That could be helpful, but how would you determine which non-Apple clang version corresponds to which Apple clang build number? Apple used to publish an approximate equivalence in the version string (so for example Apple clang 602.0.53 from Xcode 6.4 was "based on LLVM 3.6.0svn"), but they stopped doing that in Xcode 7.

Also, Apple doesn't release Xcode on the same schedule as the developers of clang release their versions. So clang 602.0.53 is based on a development version of clang sometime after the release of clang 3.5 but before the release of 3.6. So if your program requires "clang 3.6 or newer", how do you know whether 602.0.53 was far enough along in the development cycle of clang 3.6 to have the required feature or not? It might vary from program to program, as each program has different reasons for requiring newer versions of clang.

[kencu (Ken)]

Replying to ryandesign:

So if your program requires "clang 3.6 or newer", how do you know whether 602.0.53 was far enough along in the development cycle of clang 3.6 to have the required feature or not?

A fine example. So the proposal would be that:

compiler.blacklist {clang < 602} 

would also implicitly add

complier.blacklist-append macports-clang-3.3 macports-clang-3.4 macports-clang-3.5

as those are (basically) sure not to work aa well.

I wonder if this would get close enough to the desired behaviour for the vast majority of cases to prove helpful. So often you see the Portfile authour first adding the clang blacklisting, and then later on going back to add all the individual macports-clang versions once it is realized they are not able to build the software as well.

It could be overridden in the Portfile for some specific bootstrap case if needed.

[ryandesign (Ryan Carsten Schmidt)]

That sounds reasonable. So then we just need to have a method for determining which clang version corresponds to the Apple LLVM build numbers of Xcode 7 and later.

[kencu (Ken)]

this idea is not going to work out in practice as the apple clangs are not similar enough to mainline to allow this.