compiler.whitelist and compiler installation side-effects

[Ryan Schmidt]

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

> On Sunday September 20 2015 12:35:03 Ryan Schmidt wrote:
> 
>> Range filtering is already included in the compiler_blacklist_versions portgroup. An example is given in the portgroup:
> 
> Yes,
> 
>> # compiler.blacklist-append {clang >= 421.11.66 < 444}
> 
> That only applies to the Xcode clang versions, as far as I can tell.

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.


>> Trying to use "macports-clang" as the compiler name is not supported because that relies on the user having selected a version of MacPorts clang using "port select"
> 
> Why? Why would it not be possible to check if macports-clang (or clang-mp) newer or older than some version is installed, or why would it depend on having used port select?

Setting configure.compiler to "macports-clang" sets configure.cc to /opt/local/bin/clang. That doesn't exist unless the user has run "port select clang something"

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.

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:

compiler.blacklist {clang < 600} {macports-clang < 3.5} macports-clang-3.4 macports-clang-3.3

Apple and the clang project release versions at different times, so Apple clang 600 might not correspond exactly to public clang 3.5. And note also that you would need to specify both "{macports-clang < 3.5}" (to handle the version the user might have selected with "port select clang") and "macports-clang-3.4 macports-clang-3.3" to handle users who have not selected clang and users who have selected a version of clang older than 3.5.


>  Extending range selection to MacPort's clang versions only means that it becomes possible to use a short-hand notation for something that would otherwise require listing each versions concerned explicitly. It's not like it introduces a forbidden feature ...
> 
>> Looks like 3.5 and later require libc++ to exist; it doesn't exist on 10.6 unless the user puts it there per the instructions in the LibcxxOnOlderSystems wiki page.
> 
> 3.7 also fails to build on a system that does have libc++, or so at least I have been told.

That's what I assume from reading the portfiles.


> I've never bothered to install clang > 3.4 on my 10.6 system; gcc-mp-4.8+ worked just fine for me and was a lot faster than even clang 3.4 .

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