Hi,
What's the up-to-date recommendation for ports requiring C++17?
There were several different approaches, some of them probably still
in PR queue, and I kind of lost track about what a port should do now
to minimize the effort & copy-paste errors, both now and in the
future.
(I woul
Greetings,
There are two pull requests [1,2] that would allow C++17 with the line:
compiler.cxx_standard 2017
There are two stumbling blocks:
1) consensus has been elusive on the default values of
compiler.cxx_standard and compiler.c_standard [3,4]
2) there is a concern that the
The cxx11 portgroup is fine for C++11, but what do we want to do about C++14,
C++17, and future versions?
As software using c++17 is upon us, we have a slight problem with std::optional.
clang has supported std::optional for some time, and clang-9.0, at least,
appears to support std::optional right back to the ancient systems.
however, there is one small part of std::optional, std::optional::value
at do we want to do about C++14,
> C++17, and future versions?
>
On Feb 4, 2018, at 18:01, Ken Cunningham wrote:
> On Feb 4, 2018, at 6:56 PM, Ryan Schmidt wrote:
>
>> The cxx11 portgroup is fine for C++11, but what do we want to do about
>> C++14, C++17, and future versions?
>
> By providing a current clang, like 5.0, all the
Schmidt wrote:
>>>
>>> The cxx11 portgroup is fine for C++11, but what do we want to do about
>>> C++14, C++17, and future versions?
>>
>> By providing a current clang, like 5.0, all these are covered I believe.
>>
>> The PG is really misnameds
is fine for C++11, but what do we want to do about
>>>> C++14, C++17, and future versions?
>>>
>>> By providing a current clang, like 5.0, all these are covered I believe.
>>>
>>> The PG is really misnamedshould be "modern compiler" PG
gt;
>>>> On Feb 4, 2018, at 18:01, Ken Cunningham wrote:
>>>>
>>>>> On Feb 4, 2018, at 6:56 PM, Ryan Schmidt wrote:
>>>>>
>>>>> The cxx11 portgroup is fine for C++11, but what do we want to do about
>>>>> C++14, C++17,
On 4 February 2018 at 16:09, Ken Cunningham
wrote:
> Please not more portgroups, tho.
Why not?
> How about we just move up that clang floor as time goes by?
I'd actually be in favor of more explicit dependency usage. Either
creating a new portgroup or a single generic one called
compiler_featur
On Feb 4, 2018, at 20:21, Eitan Adler wrote:
> On 4 February 2018 at 16:09, Ken Cunningham wrote:
>> Please not more portgroups, tho.
>
> Why not?
They would be rather similar to one another.
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
We should think about how this will work if and
> 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 appr
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 w
Hi,
Your optional patch looks on a quick scan ok to me. To be clear, you are
proposing adding this to the llvm ports, to patch the version of the headers
installed by that, right ?
Chris
> On 5 Jul 2020, at 6:33 am, Ken Cunningham
> wrote:
>
> As software using c++17 is upon u
On Jul 5, 2020, at 00:33, Ken Cunningham wrote:
> It is quite simple (I think) to inline a function implementing
> bad_optional_access into the header. That could be used for 10.7
> to 10.12, and then all those systems could comfortably implement c++17, and
> no problem. Otherwis
>
> Chris
>
>> On 5 Jul 2020, at 6:33 am, Ken Cunningham
>> wrote:
>>
>> As software using c++17 is upon us, we have a slight problem with
>> std::optional.
>>
>> clang has supported std::optional for some time, and clang-9.0, at
12, and then all those systems could comfortably implement c++17, and
>> no problem. Otherwise we have to install a newer libc++.dylib on older
>> systems, which is a simple but big problem, as it were.
>>
>> Here’s the patch. I only speak basic c++, so improve this if you
>
>
> Then all systems from 10.5 to current can use c++17 std::optional, and
> disaster averted until the next crisis.
>
The next crisis will likely be std::filesystem, and there is no inlining that,
btw.
K
18 matches
Mail list logo
