Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?

[Jeremy Huddleston Sequoia via macports-dev]

> On Sep 26, 2019, at 21:46, Ken Cunningham <ken.cunningham.web...@gmail.com> 
> wrote:
> 
>> FYI clang-8.0, new default on 10.6.8, is very strict
>> 
>> appears will have to add to blacklist on many ports
> 
> 
> So as much as I would have put clang-5.0 first as the default compiler if the 
> system clang won't work, I understand that as some payback for all this older 
> systems support effort, it's nice to get a heads-up regarding which ports are 
> going to break with future Xcode updates, and defaulting to clang-8.0 does 
> provide that.
> 
> But the way it is now is not ideal.
> 
> When a clang-8.0 build fails, we fall back to clang-7.0, test that, then 
> clang-6.0, test that, then clang-5.0 (which builds everything).
> 
> What this means for a dev is a lot of rebuilding. Like qt4-mac. 
> 
> I know clang-8.0 fails, and clang-5.0 works. It doesn't make a lot of sense 
> to me to spend hours and hours figuring out where the real cutoff is. I can 
> just blacklist {clang-[6-9].0} , and move on, but I don't know if clang 6 can 
> build it, so that's not idea.

No, we should not blacklist compilers just because we don't want to test them.
> 
> What it means for a user is eventually four different clangs installed (5, 6, 
> 7, 8), all of them defaulted for different ports.
> 
> How about we set the list like this:
> 
> clang-8.0 -> clang-5.0 -> clang7.0 -> clang-6.0.

clang-5.0 is likely on the chopping block soon as it is also a couple years 
old.  We should really fix anything that fails to build with clang-8.

> That way, we will only have to blacklist clang-8.0 when it fails, and the 
> port will 99% of the time build with clang-5.0, and you're done.
> 
> And the end user will perhaps only have two clangs, 8.0 and 5.0, and we can 
> soon get rid of the others (6,7) which look to be obsolete soon enough.

Why would we want to keep 5.0 around and obsolete 6 and 7?  5.0 provides no 
bootstrapping benefit.

> Best,
> 
> Ken