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++.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
