compiler.whitelist and compiler installation side-effects

Ryan Schmidt ryandesign at
Wed Sep 23 13:35:38 PDT 2015

On Sep 23, 2015, at 3:05 PM, René J.V. Bertin wrote:

> On Wednesday September 23 2015 14:07:25 Ryan Schmidt wrote:
>>> True, but what you don't know is what versions there are (or are going to be at some point in the future).
>> I don't see how that matters here.
> Being able to use a range expression means you don't have to keep coming back to adapt your listing, esp. if for some reason you need to list "everything newer than this version".

So if you wanted to allow everything newer than clang 3.7.x (i.e. disallow everything older than clang 3.7.x) you might hypothetically use

compiler.fallback-prepend macports-clang
compiler.blacklist-append {macports-clang < 3.7}

And add a corresponding blacklist for Xcode clang versions.

>>> Yes, that would be a solution, though it still means that building a port (successfully) can depend on having done a port select.
>> Not depend. Optionally use.
> I've been coming at this from the situation where the compiler version does matter. In short, the port won't build (=> there's a hard dependency) unless the user does a port select, or the port itself does a fair bit of "magic".

That sounds like a busted build system which should be fixed.

> I think there are only 2 clang versions, both only available through MacPorts that will succeed in building the code; 3.4 when libc++ is not installed, and 3.4 or 3.5 when libc++ is installed.
> With hindsight I probably should have figured out how to whitelist either 3.4 or 3.5 on OS X 10.6, but that still wouldn't really address the fact that I also don't want to impose one of the versions if the user has the other installed (nor use variants).
>> My understanding of your complaint is that you do not want MacPorts to install MacPorts clang version A if the user already has MacPorts clang version B installed and version B would also work.
> Yep.
>>> My solution for Qt 5 on OS X 10.6 has been to create links to the target compiler in the port's install tree, and patch the Qmake configuration to use those links.
>> I don't understand why that would help anything. What programs are the links pointing to, and why can't you tell Qmake's configuration to use those programs directly?
> It's a port-specific implementation of port select, so that it doesn't have to rely on the user having done that.
> The problem with Qt is that it has a very annoying buildsystem that makes it (near) impossible to avoid using the Xcode toolchain. At various stages `xcrun` is used to query where to find binaries, and the result is stored in mkspec, stash or cache files. At least on 10.6 that always results in Xcode binaries being used, regardless of how you try to configure Qt.  It's a bit different when using qmake from an installed Qt toolchain, but the big hurdle is building Qt itself, not building against it. It seemed safer to store links to the actual clang binaries configured for building, I cannot remember why I decided not to store the paths to those binaries directly. I probably foresaw a possible need to use wrappers instead of binaries, wrappers that could query CC and CXX in order to reintroduce support for that standard way to control what compilers are used.

Sounds like the Qt build system sucks, and should ideally be fixed to obey the CC and CXX environment variables, like other proper build systems do. I know, Qt is an enormous project and I wouldn't want to dive into their build system to fix this either.

More information about the macports-dev mailing list