Skip to content

WIP: Build all blas-metapackages in this feedstock (also for netlib)#68

Draft
h-vetinari wants to merge 5 commits into
conda-forge:mainfrom
h-vetinari:blas_meta
Draft

WIP: Build all blas-metapackages in this feedstock (also for netlib)#68
h-vetinari wants to merge 5 commits into
conda-forge:mainfrom
h-vetinari:blas_meta

Conversation

@h-vetinari

Copy link
Copy Markdown
Member

Fixes #66, cc @minrk

Note that in the lapack-feedstock, blas-devel depends on blas, while in this feedstock, it is the other way around. I kept asking about this in #62 & #65 (because to me, the -devel version should contain more than the default), but got no answer. Still, I'm assuming that @isuruf knows very well what he's doing, so I've kept the relationship from this feedstock.

@conda-forge-linter

Copy link
Copy Markdown

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@h-vetinari

Copy link
Copy Markdown
Member Author

@conda-forge-admin, please rerender

Comment thread recipe/meta.yaml Outdated
{% set build_num = 8 %}
{% set version_major = version.split(".")[0] %}
{% set blas_major = "2" %}
{% set blas_major = "3" %}

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure if this is really necessary; it's a rather small change in the conda-forge blas infrastructure, but a change nevertheless. But it's perhaps not a bad idea to start with a clean slate - there were some collisions on this between 3.8.0 & 3.9.0 until blas_minor got introduced recently.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But it's perhaps not a bad idea to start with a clean slate

That's not a good enough reason to rebuild all downstream packages. Changing the major version will require a rebuild of all downstream packages.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wasn't aware that this requires a rebuild, agreed that that's not worth it.

Comment thread recipe/meta.yaml Outdated
Comment on lines +204 to +208
# netlib builds are build in lapack-feedstock
- pin_run_as_build('libblas', exact=True) # [blas_impl == 'netlib']
- pin_run_as_build('libcblas', exact=True) # [blas_impl == 'netlib']
- pin_run_as_build('liblapack', exact=True) # [blas_impl == 'netlib']
- pin_run_as_build('liblapacke', exact=True) # [blas_impl == 'netlib']

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is following @minrk's comment - I've never used this function and don't know how it works, thought the exact=True makes no sense to me tbh...

@h-vetinari h-vetinari marked this pull request as draft March 28, 2021 12:42
@h-vetinari h-vetinari changed the title Build all blas-metapackages in this feedstock (also for netlib) WIP: Build all blas-metapackages in this feedstock (also for netlib) Mar 28, 2021

@isuruf isuruf left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How is this going to work when there's a new version?

The other variants needs the netlib variant and therefore builds will fail

@h-vetinari

Copy link
Copy Markdown
Member Author

How is this going to work when there's a new version?

The other variants needs the netlib variant and therefore builds will fail

It work work the same as now - the netlib variants of libblas, libcblas, liblapack, liblapacke would still have to be built in the lapack-feedstock for a new lapack version, with the only difference that the blas & blas-devel meta-packages are moving to this feedstock. @minrk had more thoughts on this in #66.

@h-vetinari

Copy link
Copy Markdown
Member Author

Based on the docs for pin_run_as_build, I'm thinking this might not be the right (or best) approach. To keep the mapping between the meta-package build string and the underlying lapack version unique, I'd propose to depend on build_num of the netlib-variants.

@isuruf

isuruf commented Mar 28, 2021

Copy link
Copy Markdown
Member

This is becoming complex and messy. I don't like it. I don't see what benefits we would have. One mistake doesn't make sense to make this complex and messy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

build netlib variants of blas, blas-devel in this repo

3 participants