> On 6 May 2018, at 11:19 am, Ryan Schmidt <[email protected]> wrote: > > >> On May 6, 2018, at 05:18, Rainer Müller wrote: >> >>> On 2018-05-06 12:07, Ryan Schmidt wrote: >>> >>>> On May 5, 2018, at 19:36, Craig Treleaven wrote: >>>> >>>> A couple of times recently, I’ve noticed boilerplate in ports that require >>>> C++14. After including the compiler_blacklist_versions portgroup, they >>>> then do some gymnastics like: >>>> >>>> compiler.blacklist *gcc-3.* *gcc-4.* {*gcc-5.[0-3]} \ >>>> {clang < 800} macports-clang-3.4 >>>> macports-clang-3.5 macports-clang-3.6 macports-clang-3.7 >>>> >>>> Would it not be easier to use and maintain if we had some shorthand >>>> definitions. Maybe something like: >>>> >>>> compiler.blacklist ${min_cxx14} >>>> >>>> “min_cxx14” would be defined in the portgroup and then expand to the >>>> above...assuming the above actually does a good job of blacklisting >>>> compilers that don’t support C++14! >>>> >>>> A major advantage is that if our list of non-C++14 compilers ever changes, >>>> it only needs to be updated in one spot. >>>> >>>> I suspect there would be a few other shorthand lists that could be >>>> pre-defined. >>>> >>>> Thoughts? >>> >>> Yes, we should have support for specifying the required language >>> standard(s) in Portfile, so that MacPorts could then select a compatible >>> compiler. >>> >>> Until we have that, you need to blacklist incompatible compilers. >>> >>> If you require C++11, include the cxx11 1.1 portgroup which will do what's >>> needed for you, including blacklisting incompatible compilers and ensuring >>> the right C++ standard library is used. >>> >>> If you require C++14, include the cxx11 1.1 portgroup and additionally use >>> "compiler.blacklist-append {clang < 602}". >> >> This does not seem very intuitive. Maybe that should be put into a >> simple cxx14 port group acting as a thin wrapper as shown below? >> >> # cxx14-1.1.tcl >> PortGroup cxx11 1.1 >> compiler.blacklist-append {clang < 602} > > I didn't say it was intuitive; I just said that's how it is right now. > > Such a portgroup could be created, but I dislike the proliferation of > portgroups.
Agreed. We would already now require additional cxx14 and cxx17 portgroups, with more coming in the future (gcc8 has provisional support for the next cxx2y standard.). It just doesn’t scale well. We should, I think, instead look towards instead migrating the functionality to do this from cxx11 into a new (better named) group that can handle all the standards going forward. Like the languages group Marcus previously mentioned. Then cxx11 should be retired and ports moved over to this new group. Chris > >
