Re: removal of cxx11 PG and pre-snowleopard systems having some issues

> On Oct 6, 2019, at 7:28 PM, Joshua Root wrote: > > OK, that's certainly not expected behaviour, but it's nothing to do with > cxx11. > > - Josh Well, the ports that still have the cxx11 1.1 PG on them fall back properly to gcc-6, so from that point of view, they still work. Of course, t

Re: removal of cxx11 PG and pre-snowleopard systems having some issues

I saw the same in a dozen or so ports. It seems, at first glance, that when *gcc-3.* and *gcc-4.* are blacklisted, the fallback on PowerPC does not go to gcc-6 or gcc-7, but through to the clang chain. compiler.fallback-prepend macports-gcc-6 macports-gcc-7 in the Portfiles seems to fix it *

Re: removal of cxx11 PG and pre-snowleopard systems having some issues

On 2019-10-7 12:58 , Ken Cunningham wrote: >> Can you give specific examples, preferably with logs? On ppc, >> macports-gcc compilers are preferred over macports-clang: >> >> >> So I don't immediately see ho

Re: removal of cxx11 PG and pre-snowleopard systems having some issues

> Can you give specific examples, preferably with logs? On ppc, > macports-gcc compilers are preferred over macports-clang: > > > So I don't immediately see how what you describe could happen, unless > the

Re: removal of cxx11 PG and pre-snowleopard systems having some issues

On 2019-10-7 07:27 , Ken Cunningham wrote: > To no great surprise, as I didn’t bother to try it before now, the move from > the cxx11 PG to the new compiler spec system seems to be having some issues > on my older systems. MacPorts is calling in libomp and clang on PPC, which of > course are not

Tone/style of collaboration

Hi Chris, This is in regards to a discussion on what to do with py-tensorflow. https://trac.macports.org/ticket/59179#comment:4 Specifically, the language "I will not compromise on this.” and "Ok, you win.” doesn’t work for me in an open-source community. Regarding “you win”, this isn’t

removal of cxx11 PG and pre-snowleopard systems having some issues

To no great surprise, as I didn’t bother to try it before now, the move from the cxx11 PG to the new compiler spec system seems to be having some issues on my older systems. MacPorts is calling in libomp and clang on PPC, which of course are not (presently at least) available. So you may see tic

implementation of configure.env-append

I think I have tried this enough ways to be close, but I just want to be certain. I want to *append* a value onto an existing environment variable from a Portfile. I don’t want to overwrite what is there in the environment variable already. adding for example this in the Portfile: configure.

Re: 2.6.0 features

> On 6 Oct 2019, at 1:18 pm, Ken Cunningham > wrote: > > that is extremely sensible and what many might expect, so we should consider > adding it like that as a synonym for the compiler year, but that does also > set that flag. I also said as much when this first came about. I would suppo

Re: 2.6.0 features

that is extremely sensible and what many might expect, so we should consider adding it like that as a synonym for the compiler year, but that does also set that flag. I also said as much when this first came about. Many years ago I read that Apple (Steve) sat in a room watching people try to us

Re: 2.6.0 features

On Oct 5, 2019, at 08:37, Ken Cunningham wrote: > I have come across several ports where variant c++ standards are needed, like > gnu++11 for example, so perhaps setting the std automatically could lead to > troubles... Yeah. I had assumed that the MacPorts base feature had been implemented