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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
