compiler.whitelist and compiler installation side-effects

[René J.V. Bertin]

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

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

> 
> We could expand the version detection code in the compiler_blacklist_versions portgroup to know about the versions of clang and gcc compilers installed with MacPorts. Then, assuming you wanted to blacklist clang 3.5 and earlier you could write something like:

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

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

> But with gcc-mp-whatever you have potential C++ compatibility issues from mixing the system's older libstdc++ and MacPorts gcc's newer libstdc++.

Yeah, that's what I was told. In the end I built a large part of the KDE4 ports I use intensively like that (KDevelop, KDE PIM and others), and never had an issue. Didn't get weird errors like below in my system log either..
> Sep 21 13:00:51 Portia.local akonadi_imap_resource[5716]: dynamic_cast error 2: One or more of the following type_info's  has hidden visibility.  They should all have public visibility.   N7Akonadi11PayloadBaseE, N7Akonadi7PayloadIN5boost10shared_ptrIN5KMime7MessageEEEEE, N7Akonadi7PayloadIN5boost10shared_ptrIN5KMime7MessageEEEEE.

R.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macports_clang_selection-1.0.tcl
Type: text/x-tcl
Size: 8682 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150923/3a2e0a6c/attachment-0001.bin>