Re: cxx11 portgroup: C++11, C++14, C++17

[Ryan Schmidt]

On Feb 4, 2018, at 21:51, Ken Cunningham wrote:
> 
> On Feb 4, 2018, at 9:36 PM, Ryan Schmidt wrote:
> 
>> We should think about how this will work if and when it is integrated into 
>> MacPorts base and not a portgroup. I think starting with configure.cc_std 
>> and configure.cxx_std might work well.
> 
> I’m trying to really understand your approach here, which I recognize to be 
> to use the oldest compiler that can do the job.

Not exactly. If /usr/bin/clang can build the port, I want to use that. I don't 
want to unnecessarily require a newer clang from MacPorts. Besides saving users 
disk space and time, this will make builds on the buildbot go quicker as it 
doesn't have to activate and then later deactivate those compiler files.

If /usr/bin/clang is too old to build a port, then sure, use the newest stable 
clang. The blacklist/fallback mechanism in MacPorts base is meant to handle 
that correctly. When it gets out of date (i.e. a new stable version of clang 
appears) it needs to be updated and a new version of MacPorts base released.


> In my mind, I’d use the newest compiler that the systems can run. 
> 
> I know you don’t agree with that, but:
> 
> 1. all consistent across the systems
> 2. less testing, less tickets, less crapola to deal with
> 3. newer optimizations, better speed, etc
> 4. only port builders need to install the compiler - and they likely want it 
> anyway. Users installing the ports don’t have to, they just download the 
> built products off the buildbots.

Some ports are not distributable. Quite a lot of the ports that depend on 
openssl directly or indirectly are not distributable because of the 
interactions between the openssl license and the gpl. Quite a lot of ports 
eventually depend on openssl. Some of these may be because ports neglect to 
specify that they may use the openssl license exception for gpl software, and 
we should fix those.

> 5. fewer requests for upstream to hold back to old compiler standards they 
> don’t want to support anyway...

I'm not saying we should request developers restrict themselves to old language 
standards. I'm saying MacPorts base should provide a mechanism by which ports 
can specify what language standards they require, so that MacPorts can 
automatically select a compiler that supports those standards.

> So long as you can bootstrap to the new compiler, why not go with that?
> 
> So with this in mind, I’d flush everyone who is not running a current system 
> (past three say) to clang-5.0, or 6.0 if that’s stable enough now.
> 
> Easy, quick, done…
> 
> Ken

Re: cxx11 portgroup: C++11, C++14, C++17

[Ken Cunningham]

> On Feb 4, 2018, at 9:36 PM, Ryan Schmidt  wrote:
> 

> We should think about how this will work if and when it is integrated into 
> MacPorts base and not a portgroup. I think starting with configure.cc_std and 
> configure.cxx_std might work well.
> 


I’m trying to really understand your approach here, which I recognize to be to 
use the oldest compiler that can do the job.

In my mind, I’d use the newest compiler that the systems can run. 

I know you don’t agree with that, but:

1. all consistent across the systems
2. less testing, less tickets, less crapola to deal with
3. newer optimizations, better speed, etc
4. only port builders need to install the compiler - and they likely want it 
anyway. Users installing the ports don’t have to, they just download the built 
products off the buildbots.
5. fewer requests for upstream to hold back to old compiler standards they 
don’t want to support anyway...

So long as you can bootstrap to the new compiler, why not go with that?

So with this in mind, I’d flush everyone who is not running a current system 
(past three say) to clang-5.0, or 6.0 if that’s stable enough now.

Easy, quick, done…

Ken

Re: cxx11 portgroup: C++11, C++14, C++17

[Ryan Schmidt]

On Feb 4, 2018, at 20:21, Eitan Adler wrote:

> On 4 February 2018 at 16:09, Ken Cunningham wrote:
>> Please not more portgroups, tho.
> 
> Why not?

They would be rather similar to one another.

https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

We should think about how this will work if and when it is integrated into 
MacPorts base and not a portgroup. I think starting with configure.cc_std and 
configure.cxx_std might work well.

>> How about we just move up that clang floor as time goes by?
> 
> I'd actually be in favor of more explicit dependency usage. Either
> creating a new portgroup or a single generic one called
> compiler_features or whatnot.

Re: cxx11 portgroup: C++11, C++14, C++17

[Eitan Adler]

On 4 February 2018 at 16:09, Ken Cunningham
 wrote:
> Please not more portgroups, tho.

Why not?

> How about we just move up that clang floor as time goes by?

I'd actually be in favor of more explicit dependency usage. Either
creating a new portgroup or a single generic one called
compiler_features or whatnot.


-- 
Eitan Adler

Re: cxx11 portgroup: C++11, C++14, C++17

[Ken Cunningham]

Somewhere in the tickets Marcus has this at least 1/2 done...

K

Sent from my iPhone

> On Feb 4, 2018, at 7:14 PM, Ryan Schmidt  wrote:
> 
> 
>> On Feb 4, 2018, at 18:09, Ken Cunningham wrote:
>> 
>>> On Feb 4, 2018, at 7:03 PM, Ryan Schmidt wrote:
>>> 
 On Feb 4, 2018, at 18:01, Ken Cunningham wrote:
 
> On Feb 4, 2018, at 6:56 PM, Ryan Schmidt wrote:
> 
> The cxx11 portgroup is fine for C++11, but what do we want to do about 
> C++14, C++17, and future versions?
 
 By providing a current clang, like 5.0, all these are covered I believe. 
 
 The PG is really misnamedshould be "modern compiler" PG or similar.
>>> 
>>> Well, for example, Apple clang < 602 doesn't understand -std=c++14, but the 
>>> portgroup only blacklists clang < 500. So for C++14 ports like textmate2 
>>> I've been adding the clang < 602 blacklist in addition to including the 
>>> portgroup. But the more new C++ standards get introduced, the more 
>>> complicated this will get.
>> 
>> Please not more portgroups, tho.
> 
> Agreed. That was the point I want to raise. And if we want a single portgroup 
> that handles specifying different language standards, it makes sense to 
> rename it now, before we go changing all the cxx11 1.0 ports, so that we 
> don't have to change those ports again a second time.
> 
> 
>> How about we just move up that clang floor as time goes by?
> 
> I would not be in favor of that, because it would result in users 
> unnecessarily being forced to install newer compilers for ports that don't 
> need them.
> 
> I would be in favor of a new option in which the port author can specify the 
> language standard, and the portgroup takes care of the details. Actually 
> there should probably be an option for each language: maybe configure.cc_std 
> and configure.cxx_std.
> 

Re: cxx11 portgroup: C++11, C++14, C++17

[Ryan Schmidt]

On Feb 4, 2018, at 18:09, Ken Cunningham wrote:

> On Feb 4, 2018, at 7:03 PM, Ryan Schmidt wrote:
> 
>> On Feb 4, 2018, at 18:01, Ken Cunningham wrote:
>> 
>>> On Feb 4, 2018, at 6:56 PM, Ryan Schmidt wrote:
 
 The cxx11 portgroup is fine for C++11, but what do we want to do about 
 C++14, C++17, and future versions?
>>> 
>>> By providing a current clang, like 5.0, all these are covered I believe. 
>>> 
>>> The PG is really misnamedshould be "modern compiler" PG or similar. 
>> 
>> Well, for example, Apple clang < 602 doesn't understand -std=c++14, but the 
>> portgroup only blacklists clang < 500. So for C++14 ports like textmate2 
>> I've been adding the clang < 602 blacklist in addition to including the 
>> portgroup. But the more new C++ standards get introduced, the more 
>> complicated this will get.
> 
> Please not more portgroups, tho. 

Agreed. That was the point I want to raise. And if we want a single portgroup 
that handles specifying different language standards, it makes sense to rename 
it now, before we go changing all the cxx11 1.0 ports, so that we don't have to 
change those ports again a second time.


> How about we just move up that clang floor as time goes by? 

I would not be in favor of that, because it would result in users unnecessarily 
being forced to install newer compilers for ports that don't need them.

I would be in favor of a new option in which the port author can specify the 
language standard, and the portgroup takes care of the details. Actually there 
should probably be an option for each language: maybe configure.cc_std and 
configure.cxx_std.

Re: cxx11 portgroup: C++11, C++14, C++17

[Ken Cunningham]

Please not more portgroups, tho. 

How about we just move up that clang floor as time goes by? 

K

Sent from my iPhone

> On Feb 4, 2018, at 7:03 PM, Ryan Schmidt  wrote:
> 
>> On Feb 4, 2018, at 18:01, Ken Cunningham wrote:
>> 
>>> On Feb 4, 2018, at 6:56 PM, Ryan Schmidt wrote:
>>> 
>>> The cxx11 portgroup is fine for C++11, but what do we want to do about 
>>> C++14, C++17, and future versions?
>> 
>> By providing a current clang, like 5.0, all these are covered I believe. 
>> 
>> The PG is really misnamedshould be "modern compiler" PG or similar. 
> 
> Well, for example, Apple clang < 602 doesn't understand -std=c++14, but the 
> portgroup only blacklists clang < 500. So for C++14 ports like textmate2 I've 
> been adding the clang < 602 blacklist in addition to including the portgroup. 
> But the more new C++ standards get introduced, the more complicated this will 
> get.
> 

Re: cxx11 portgroup: C++11, C++14, C++17

[Ken Cunningham]

By providing a current clang, like 5.0, all these are covered I believe. 

The PG is really misnamedshould be "modern compiler" PG or similar. 

K

Sent from my iPhone

> On Feb 4, 2018, at 6:56 PM, Ryan Schmidt  wrote:
> 
> The cxx11 portgroup is fine for C++11, but what do we want to do about C++14, 
> C++17, and future versions?
>