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

[Jeremy Huddleston Sequoia]

> On Sep 26, 2019, at 21:46, Ken Cunningham <ken.cunningham.webuse at 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