Compiler blacklist 'shorthand'

[Chris Jones]

> On 6 May 2018, at 11:19 am, Ryan Schmidt <ryandesign at macports.org> 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
> 
>