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
