Make Compiler Dependency Explicit

[Richard L. Hamilton]

I've hit some ports yesterday on Snow Leopard (only have one that old) that require clang-3.9...but clang-3.9 is deemed superseded by clang-8.0, except the ones with clang-3.9 dependencies won't use that, so it's a no-win upgrading those. The problematic ports:
py27-cython
xorg-libXevie
xorg-libXfontcache
xorg-libXp
xorg-xorgproto


> On Jul 11, 2019, at 20:09, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
> On Jul 11, 2019, at 18:47, Jahrme Risner wrote:
> 
>> As for the compiler blacklist/whitelist/fallback, I was using what was already provided, but if we can make it even more intelligent, that would be wonderful. If I understand you correctly, a Portfile should use either blacklist+fallback OR a whitelist as using the whitelist makes the other two lists largely redundant.
>> 
>> If that is correct, what would you suggest as the best setup to require a GNU gcc? The current blacklist includes:
>> - *clang*
>> - *llvm-gcc*
>> - *apple-gcc*
>> - gcc
>> - gcc-3.3
>> - gcc-4.0
>> - gcc-4.2
>> This was crafted to ban all of Apple's fake gccs which are actually clang/llvm in disguise.
> 
> I guess it would suffice to use:
> 
> compiler.blacklist *clang* gcc *gcc-3.* *gcc-4.*
> compiler.fallback-append macports-gcc-[whatever version you want]
> 
> though my guidance to avoid setting the whitelist is aimed more at ports that do build using a recent clang but not with older clangs. In this case, I've seen non-ideal constructions used before, in which the intention was to prohibit the use of older clangs and to specify the use of a newer clang, but which, because a specific clang that was new at the time was specified, and because newer clangs were added to the default list in MacPorts base over time, actually resulted in a rather old version of clang being forced instead of the current version which would have worked fine.
> 
>