OpenBLAS binary packages

Dear MacPorts users and developers, I am trying to understand why I am not able to get the OpenBLAS port to install exclusively from binary packages, i.e. using something like: sudo port -b install OpenBLAS Even if I prepare a local repository with the prebuilt binary packages it indicates tha

no destroot found (was: help please)

> what does this mean … > > [haycorn] /Users/jam/DEVEL [580]% sudo port install qt511-qtwebkit > ---> Computing dependencies for qt511-qtwebkit > ---> Installing qt511-qtxmlpatterns @5.11.3_0 > Error: Failed to install qt511-qtxmlpatterns: no destroot found at: > /opt/local/var/macports/build/_

Re: OpenBLAS binary packages

Hi, Its not possible to get binary installs for OpenBLAS due to license conflicts between it and one of its deps, openssl IIRC. Because of this the buildbots flag the builds as non-distributable. Chris On 15/05/2019 9:18 am, Artur Szostak wrote: Dear MacPorts users and developers, I am try

Re: OpenBLAS binary packages

> Its not possible to get binary installs for OpenBLAS due to license > conflicts between it and one of its deps, openssl IIRC. Because of this > the buildbots flag the builds as non-distributable. OK. But again. If I am trying to get the thing installed from a local repository of my own prebuilt

Re: OpenBLAS binary packages

> I am trying to understand why I am not able to get the OpenBLAS port to > install exclusively from binary packages, i.e. using something like: > sudo port -b install OpenBLAS > Even if I prepare a local repository with the prebuilt binary packages it > indicates that it is not able to find an

Re: OpenBLAS binary packages

On 15/05/2019 9:35 am, Artur Szostak wrote: Its not possible to get binary installs for OpenBLAS due to license conflicts between it and one of its deps, openssl IIRC. Because of this the buildbots flag the builds as non-distributable. OK. But again. If I am trying to get the thing installed

Re: no destroot found (was: help please)

mac > On 15 May 2019, at 4:22 pm, Joshua Root wrote: > >> what does this mean … >> >> [haycorn] /Users/jam/DEVEL [580]% sudo port install qt511-qtwebkit >> ---> Computing dependencies for qt511-qtwebkit >> ---> Installing qt511-qtxmlpatterns @5.11.3_0 >> Error: Failed to install qt511-qtxmlpa

Re: OpenBLAS binary packages

OK, I must be blind. Thanks for indicating archive_sites. I completely missed that when looking at the Portfile yesterday. This explains everything. This raises the question: how is the MacPorts team mitigating the cost of compiling OpenBLAS over and over again when trying to prepare production

Re: OpenBLAS binary packages

Chris Jones wrote: > Its not possible to get binary installs for OpenBLAS due to license > conflicts between it and one of its deps, openssl IIRC. Because of this > the buildbots flag the builds as non-distributable. That's often the reason why binary packages are not available, but not in this

Re: OpenBLAS binary packages

On 15/05/2019 10:37 am, Joshua Root wrote: Chris Jones wrote: Its not possible to get binary installs for OpenBLAS due to license conflicts between it and one of its deps, openssl IIRC. Because of this the buildbots flag the builds as non-distributable. That's often the reason why binary pa

Re: OpenBLAS binary packages

On 2019-5-15 19:01 , Artur Szostak wrote: > OK, I must be blind. Thanks for indicating archive_sites. I completely missed > that when looking at the Portfile yesterday. This explains everything. > > This raises the question: how is the MacPorts team mitigating the cost of > compiling OpenBLAS ov

Re: OpenBLAS binary packages

Hi, On 15/05/2019 10:47 am, Joshua Root wrote: On 2019-5-15 19:01 , Artur Szostak wrote: OK, I must be blind. Thanks for indicating archive_sites. I completely missed that when looking at the Portfile yesterday. This explains everything. This raises the question: how is the MacPorts team miti

Re: OpenBLAS binary packages

I fear there is also a procedural and policy enforcement issue here. Clearly different people have implemented things in different ways, giving a non-standard and non-uniform look and feel to MacPorts ports. It makes for a poor user experience and the MacPorts community look bad. After our 4 ye

Re: OpenBLAS binary packages

Hi, > The Portfile does disable the use of binary archives, by clearing the > archive_sites option. > > > The assumption seems to be that if you are using OpenBLAS, then you must > require maximum performance

Re: OpenBLAS binary packages

Now that OpenBLAS became more widely used and is now a dependency for several other ports, I could look into making a ‘generic’ version as suggested, if it is considered preferable to reduce the building time at the cost of performance. I would have to confirm if a generic version could also

Re: OpenBLAS binary packages

> On May 15, 2019, at 22:04, Chris Jones wrote: > > >> Now that OpenBLAS became more widely used and is now a dependency for >> several other ports, I could look into making a ‘generic’ version as >> suggested, if it is considered preferable to reduce the building time at the >> cost of pe

Re: help please

> On May 15, 2019, at 12:58 AM, James Linder wrote: > > Error: Failed to install qt511-qtxmlpatterns: no destroot found at: Appears you’ve run into an intermittent problem with MacPorts that we’ve unfortunately never been able to track down and fix. See: https://trac.macports.org/wiki/Proble

Re: OpenBLAS binary packages

On May 15, 2019, at 07:36, Nicolas Pavillon wrote: > Now that OpenBLAS became more widely used and is now a dependency for several > other ports, I could look into making a ‘generic’ version as suggested, if it > is considered preferable to reduce the building time at the cost of > performan

Re: OpenBLAS binary packages

On May 15, 2019, at 04:01, Artur Szostak wrote: > This raises the question: how is the MacPorts team mitigating the cost of > compiling OpenBLAS over and over again when trying to prepare production > binary packages for other ports where OpenBLAS happens to be in the > dependency tree? We

Re: OpenBLAS binary packages

On Wed, 15 May 2019 at 12:23, Artur Szostak wrote: > > After our 4 years of experience preparing RPM and MacPorts package > repositories of our software we have seen that MacPorts packages take an > order of magnitude more time to build and cause significantly more problems > than RPMs. Mainly