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

[Ken Cunningham]

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

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.

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.

Best,

Ken