Re: Universal packaging tool (for pypi, cpan, ruby, ...)

Hey, On 12.02.19 03:40, Cyril Roelandt wrote: > I'm the author of upt. Thanks for joining the discussion! > On 2019-02-10 21:24, Mojca Miklavec wrote: >> Hi, >> >> Last week I was sitting in cafeteria with the author of a new python >> package "upt" (Universal packaging tool) whose aim is to pro

Re: compilers that support thread-local storage?

Or ... maybe not! Looks like the cxx11 1.1 PG conflicts with the compilers PG & I end up with just g95 for the Fortran compiler selection ... oops! I'll just replicate the compiler blocklist per your description & go with that. Will work on older OSX & won't harm on newer OSX. - MLD On Wed, Feb

Re: compilers that support thread-local storage?

On 2019-02-13, at 10:23 AM, Ken Cunningham wrote: > For Xcode clang, you already have that -- 900+ You already had the more accurate Xcode clang version -- 900 is not right, it's the one you said. K

Re: compilers that support thread-local storage?

OK wow that's quite the analysis! I'm going to go with just incorporating the c++11 1.1 PG ... it'll work for now, and once "we" get around to dealing with the changes to base from PR #88, it'll be a "universal" change to all Portfiles that use c++11 PGs ... so we'd be good to go! Thanks! - MLD

Re: compilers that support thread-local storage?

__thread came first, then thread_local a bit later. the difference is that thread_local allows more complicated initializers and destructors ("non-trivial"). It is c++11, as you said. quite old gcc versions support __thread I think the earliest one was gcc 4.1

compilers that support thread-local storage?

I'm wondering what the correct blacklist is to get compilers that support thread local storage. I've found some Portfiles that state just: {{{ compiler.blacklist-append {clang < 800.0.38} }}} which isn't enough since I know that the old Apple GCC and LLVM versions from 4.2 and older won't work .

Re: Universal packaging tool (for pypi, cpan, ruby, ...)

Dear Mojca, My use case is far more ambitious. Thanks for the feedback though. Kind regards. Artur From: Mojca Miklavec Sent: 13 February 2019 09:38:35 To: Artur Szostak Cc: Cyril Roelandt; MacPorts Development Subject: Re: Universal packaging tool (for

Re: Universal packaging tool (for pypi, cpan, ruby, ...)

Dear Artur, On Wed, 13 Feb 2019 at 09:18, Artur Szostak wrote: > > What is the current practical reality of tools like upt? i.e. how well do > they behave on real packages. For example, if I take all the .src.rpm > packages in say the Fedora repository, and attempt to convert them to > MacPorts

Re: Universal packaging tool (for pypi, cpan, ruby, ...)

What is the current practical reality of tools like upt? i.e. how well do they behave on real packages. For example, if I take all the .src.rpm packages in say the Fedora repository, and attempt to convert them to MacPorts packages, what percentage of the converted packages will actually work ou