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 <[email protected]> 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. > >
