compiler.whitelist and compiler installation side-effects

Ryan Schmidt ryandesign at macports.org
Wed Sep 23 12:07:25 PDT 2015


On Sep 22, 2015, at 7:22 PM, René J.V. Bertin wrote:

> On Tuesday September 22 2015 18:39:13 Ryan Schmidt wrote:
> 
>> That's correct. The compiler_blacklists_versions portgroup only knows how to interpret the Apple-sepcific version numbers Apple assigns to its compilers in Xcode. I didn't add version detection for compiler ports provided by MacPorts because I thought it was unnecessary because we already know what version they are.
> 
> 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.


>> But I just tried setting "compiler.whitelist macports-clang clang" in a port. Then I used "port select clang mp-clang-3.4" and tried to configure the port. It used /opt/local/bin/clang-mp-3.4. Then I used "port select clang none" and cleaned and reconfigured the port. It used /usr/bin/clang. So it looks like this might actually be ok: it would use the version of MacPorts clang the user selected, if the user selected one, and Xcode clang otherwise.
> 
> 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.

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. My proposal should partially address that complaint, by allowing the user to use "port select clang" to indicate a version of clang that they prefer. If a port blacklists all Xcode compilers and needs to fall back to a MacPorts clang compiler, and the user's selected clang compiler is compatible with the port, then it would be used. If not, MacPorts would select (and install, if not already installed) a different MacPorts clang compiler based on the existing fallback rules.


> There's also the question what happens when multiple ports whitelist macports-clang but have different requirements; you'd have to select the appropriate version manually and couldn't do a `upgrade outdated` when 2 or more of such ports are outdated. May not happen often, but it could.

Not relevant / not a problem. The port would indicate what versions of clang are acceptable, via the normal compiler_blacklist_versions syntax. If the user's selected version if not compatible, MacPorts will install and use a different version of clang.

And let me state again that using compiler.whitelist is unusual. Usually you should only use compiler.blacklist and perhaps compiler.fallback.


> 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?


> I've whipped up some attempts of my own which have a similar effect (but without the nice syntax). But to remain true to the reproducible build the simplest solution might be a function or variable that returns/contains either the latest version that's known to work on the host OS, or else the current latest stable release. That would be clang-3.4 on OS X <=10.6 without libc++; 3.5 with libc++, and 3.6 otherwise. That should cover most cases, as long as newer versions don't introduce severe regressions (and I suppose `clang` behaves the same way, in compiler.whitelist).

I don't think we need any function to return the latest stable version of clang for an OS X version. If anything, we could improve the default value of compiler.fallback in MacPorts base, so that it returns newer versions of clang than 3.4 when libc++ is in use (assuming it's possible to determine that at that point in the code).


> There's also the question whether the compiler should be recorded as build dependency of ports that impose a specific version.

MacPorts already does record the compiler port as a build dependency.


On Sep 22, 2015, at 7:24 PM, René J.V. Bertin wrote:

> On Tuesday September 22 2015 19:01:39 Ryan Schmidt wrote:
> 
>> Well, I suppose the compiler_blacklist_versions portgroup could be smartened to automatically add "macports-clang-3.4 macports-clang-3.3" if you specify "{macports-clang < 3.5}".
> 
> Is it me or does this look like there are multiple Ryans discussing among themselves here? :)

I try to craft my emails carefully, often proof-reading and rewriting them several times before sending. Still, sometimes I realize after sending that something I said could be improved, so I'll reply to myself.






More information about the macports-dev mailing list