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

[Chris Jones]

Hi,

I would not be particularly in favour of changing things as you suggest. 
For me the defaults as they are are correct. They should start with the 
newest clang available and work back, in order.

For specific ports that have issues, either fix the port to work with a 
recent clang, or if not practical you can always explicitly set the 
fallback or whitelist to be whatever ports you want, in whatever order. 
I would prefer to hacks like this specific to each port that needs them, 
not hidden away in base, just to make it clear when looking at the port 
file itself what is going on.

Also personally I have no issue with a mixture of macports clangs being 
used by ports, so don't see the issue with a user having to have a 
number installed. Most users get prebuilt binaries anyway.

Chris

On 27/09/2019 5:46 am, Ken Cunningham 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.
> 
> 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
>