On May 6, 2018, at 05:27, Chris Jones wrote:
> On 6 May 2018, at 11:19 am, Ryan Schmidt 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.
As I've said in a different thread some months ago, I think it should be in
base.