Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?
Apple does a lot in it's clang fork to relax the restrictiveness. Seriously, set your default compilers to what 10.6.8 has to live with; at least share in it with us! But I can see I'm outvoted here. My great dream of no older systems tickets dies. :) K > On Sep 28, 2019, at 01:14, Chris Jones wrote: > > > >> On 27 Sep 2019, at 3:06 pm, Ken Cunningham >> wrote: >> >> I think it would be fair to invite everyone to try setting the default >> compiler list for a week on your own systems to our current macports clang >> progression! >> >> Compilers are always ahead of the codebase by a couple of years. >> >> What are the clang-using Linux distros defaulting, I wonder? That might tell >> us where they feel the codebase is presently... > > Our point of reference should be the Xcode clang versions. Most ports build > fine on 10.14 using the system clang there, so what upstream version does > this equate to , roughly ? My guess based on release times would be somewhere > are clang 7. > > I am with Jeremy here, we need to start pushing away from clang 5. > > Chris > >> >> Ken >> >
Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?
> On 27 Sep 2019, at 3:06 pm, Ken Cunningham > wrote: > > I think it would be fair to invite everyone to try setting the default > compiler list for a week on your own systems to our current macports clang > progression! > > Compilers are always ahead of the codebase by a couple of years. > > What are the clang-using Linux distros defaulting, I wonder? That might tell > us where they feel the codebase is presently... Our point of reference should be the Xcode clang versions. Most ports build fine on 10.14 using the system clang there, so what upstream version does this equate to , roughly ? My guess based on release times would be somewhere are clang 7. I am with Jeremy here, we need to start pushing away from clang 5. Chris > > Ken >
Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?
> On Sep 26, 2019, at 21:46, 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.
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
Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?
I think it would be fair to invite everyone to try setting the default compiler list for a week on your own systems to our current macports clang progression! Compilers are always ahead of the codebase by a couple of years. What are the clang-using Linux distros defaulting, I wonder? That might tell us where they feel the codebase is presently... Ken
Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?
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
Re: clang-8.0 very strict -- can we think about changing the clang compiler list order?
> 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
clang-8.0 very strict
FYI clang-8.0, new default on 10.6.8, is very strict appears will have to add to blacklist on many ports or otherwise surgerize code/standard setting — eventually will have to happen but all at once is daunting downgrading default compiler on 10.6.8 to clang-5.0 gets the rev-upgrade done once system is restored and working again will go back and try to start in on the clang-8.0 blacklisting K
