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
