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…