compiler.whitelist and compiler installation side-effects

Ryan Schmidt ryandesign at macports.org
Sun Sep 20 09:43:21 PDT 2015


On Sep 20, 2015, at 8:06 AM, René J. V. Bertin wrote:

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

I don't know if that would work but it was not intended to work that way.


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

No, MacPorts does not have the feature you are asking for.


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

Technically that might accomplish what you want. But I don't think I would like to see blocks like this appearing in ports. If this functionality is desired, probably it should go into MacPorts base, not individual ports.

For now, individual ports should continue to just blacklist compilers with which they're known not to work. Most ports don't have a reason to touch compiler.whitelist.



On Sep 20, 2015, at 8:47 AM, René J.V. Bertin wrote:

> On Sunday September 20 2015, Brandon Allbery wrote:
> 
>> The point of the whitelist is to deal with buggy compilers. If 3.7 is
>> preferred then it usually means that 3.6 can't build a working version of
>> the port; as such, it would be expected to install a compiler that will
> 
> If that is the case, (macports-)clang-3.6 should be BLACKlisted, not whitelisted (and my arguments stand ...)
> It makes no sense to put items on a white list that are not to be used.
> 
>> `port select` should never affect what compiler is used to build a port; if
>> it does, that is a bug.
> 
> The "Using the right compiler" page lists "macports-clang" as "the MacPorts clang version selected via port select" (or words to that effect). If that token isn't supposed to be used in a whitelist it should be documented

I'm not comfortable with the UsingTheRightCompiler page mentioning the "cc", "gcc", "macports-gcc" or "macports-clang" options because in my opinion they should never be used. They shouldn't even exist in MacPorts. I'm sure I've argued about this before and someone else argued for why they should stay, and they stayed.

IIRC, "cc" exists only for compatibility with Linux, which is needed because MacPorts needs to run on Linux in order to generate the list of ports that are imported into the database that powers the web site.


>> Compilers you have installed manually (i.e. not via MacPorts) should not be
>> used to build ports; if one is, that is a bug.
> 
> Is there any particular reason to disallow using Intel's compiler, rather than discourage it because of lack of testing? (or Xcode, if you take the above to the letter ^^)


What would be the reason to allow it?

MacPorts is not about providing users with every possible option; it's about providing users with a working way to install software on their Macs. If there exists a piece of software that cannot be compiled with clang or gcc or any other compiler in MacPorts, but that can be compiled with the Intel compiler, then that would be a reason to modify that one port to require and use the Intel compiler. Otherwise, I don't see a reason.






More information about the macports-dev mailing list