compiler.whitelist and compiler installation side-effects

[René J. V. Bertin]

Ryan Schmidt wrote:

> 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

That's as I feared. So is there a way to achieve what I'd hope for (and expect 
from a whitelisting feature *)!), for instance by something like {macports-clang 
>= 3.4}? I tried (after blacklisting my own Xcode clang first) and at least this 
doesn't try to install a newer version than the 3.6 I have installed myself ... 
but I haven't tried if it actually tries to install a MacPorts clang version if 
none is available.

If this feature is not currently implemented it would be nice to have, I cannot 
imagine being the first to run into the (very) significant of installing a clang 
version (from source...) despite having a whitelisted version available, and 
wonder what's happening.

Maybe this could be as simple (not to say crude) as

foreach v {3.7 3.6 3.5 3.4} {
    if {[file exists ${prefix}/libexec/llvm-${v}/bin/clang]} {
        compiler.whitelist-append macports-clang-${v}
    }
}

combined with a way to set a fallback version.

BTW, what happens if you whitelist macports-clang and haven't used port select?

*) a white list is a list of acceptable items which is checked against what's 
available, just like a black list is a list that is checked to see which 
available things that are not acceptable. The current whitelist implementation 
functions more like a set of alternative build dependencies from which the first 
is picked that *can* apply.

R.