conda-forge/openblas-feedstock

Split out static library

Closed this issue · 11 comments

The static library for openblas is quite large, and won't be needed by most users.

$ du -hc /Users/jcrist/miniconda3/envs/testenv/lib/libopenblasp-r0.3.6.a
 62M    /Users/jcrist/miniconda3/envs/testenv/lib/libopenblasp-r0.3.6.a
 62M    total

It would be good to split it out into a separate package.

Defaults ships this as libopenblas-static (see #54 (comment))

I'm 👍 on splitting. @isuruf you are our blas expert, what do you think?

Sure. I'd just leave the static library in openblas along with the headers and split the dynamic libraries into libopenblas and make blas-feedstock depend on libopenblas.

I believe that is similar to what AR is doing here, right?

https://github.com/AnacondaRecipes/openblas-feedstock/blob/master/recipe/meta.yaml

PS: we have two failing PRs trying to sync with AR #55 and #52, time for a thrid one 😄

I don't find it useful to have 4 packages there.
I'd just have libopenblas and openblas (which is going to be openblas, libopenblas-static, openblas-devel in defaults merged together)

While I agree with you it would be nice to know why @mingwandroid chose to split it that way and the advantages of staying in sync (interoperability of recipes is nice to have).

To save space for those who care not for static libraries (nearly everyone).

To save space for those who care not for static libraries (nearly everyone).

@mingwandroid please see the comment about the 4 subpackages in @isuruf's #69 (comment).

The static splitting is happening BTW.

I prefer openblas be an empty metapackage as it stands to be honest with you. It's there for old recipes, so that their dependencies on openblas still work as expected. I believe my split is more logical too, but overall I don't mind and I think we'd resync to whatever is decided as best.

Done in #70.

Needs conda-forge/blas-feedstock#31 to make use of libopenblas