compiler.whitelist and compiler installation side-effects

[René J.V. Bertin]

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

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

>so I'll reply to myself.

I won't judge you, me I lecture my computer. Or myself ^^

R.