On Sep 20, 2015, at 6:06 AM, René J.V. Bertin wrote:
> What are the exact effects in terms of compiler installation when I set?
>
> compiler.whitelist clang macports-clang-3.7 macports-clang-3.6
> macports-clang-3.5 macports-clang-3.4
> compiler.blacklist-append macports-llvm-gcc-4.2 llvm-gcc-4.2
> compiler.blacklist-append gcc-4.2 apple-gcc-4.2 gcc-4.0
> compiler.blacklist-append macports-clang-3.1 macports-clang-3.0
> macports-clang-3.2 macports-clang-3.3
> compiler.blacklist-append {clang < 500}
>
> I have a user telling me clang 3.7 is being installed (from source, I fear)
> while he has port:clang-3.5 installed (or port:clang-3.6 by now), and as far
> as I'm concerned that is not desired behaviour.
>
> What I'd expect is:
> 1- accept either of the installed compilers in the list, e.g. v3.5 if it's
> available
> 2- if none are available, install the first from the list (= give the dev a
> means to prefer the latest version)
>
> 1) appears not to be met. 2) doesn't go for the system compiler because
> clang<500 applies on the user's system.
When you use compiler.whitelist, you're telling MacPorts to use the first of
those compilers that exist and that does not match an entry in the blacklist.
So if Xcode provides clang, and it is not blacklisted by a compiler.blacklist
rule, that is the compiler that will be used. If Xcode does not provide clang,
or if Xcode clang matches a blacklist rule (for example in your case, if Xcode
clang is < build 500), then if macports-clang-3.7 exists (which it does),
macports-clang-3.7 will be used (being installed first if it is not already
installed). The remaining whitelist entires will not do anything, nor will the
compiler.blacklist entries that mention compilers other than Xcode clang.
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
