Build for 3.9.0

[h-vetinari]

Checklist

• Used a fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Version 3.9.0 has been released for a while, let's try building for it.

@conda-forge-admin, please rerender

[conda-forge-linter]

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.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-webservice.

I tried to re-render for you but ran into some issues, please ping conda-forge/core for further assistance. You can also try re-rendering locally.

[h-vetinari]

Comments on the changes

[h-vetinari]

The url for the sources changed between 3.8.0 and 3.9.0

[h-vetinari]

This was noted as a hack in a5df20d, can we document what's necessary to remove it?

[h-vetinari]

Same here - which conda-build bug is relevant here? What would be necessary to simply use:

      host:
        - {{ pin_subpackage("libblas", exact=True) }}
        - {{ pin_subpackage("libcblas", exact=True) }}
      {% if blas_impl != 'blis' %}
        - {{ pin_subpackage("liblapack", exact=True) }}
        - {{ pin_subpackage("liblapacke", exact=True) }}
      {% endif %}

[h-vetinari]

OK, clearly I misunderstood this recipe, and how it's necessary to build https://github.com/conda-forge/lapack-feedstock for 3.9.0 first.

Edit: conda-forge/lapack-feedstock#32
Edit2: also note that blis=0.6.1 failed to build for windows after merging the PR in the feedstock. See conda-forge/blis-feedstock#12

[h-vetinari]

I rebased this in anticipation of conda-forge/lapack-feedstock#32 hopefully being finished soon.

I have to say that I really had trouble wrapping my head around this recipe. I couldn't understand (from the meta.yaml) how libblas depends on the netlib implementation:

PackagesNotFoundError: The following packages are not available from current channels:

  - libcblas==3.9.0[build=*netlib]
  - liblapacke==3.9.0[build=*netlib]
  - liblapack==3.9.0[build=*netlib]
  - libblas==3.9.0[build=*netlib]

It took me a while to find out that that dependency only appears in build.sh (which also gets called in bld.bat, but curiously doesn't error the build upon failing).

Also, why do we download the netlib-sources again if the build is already done in the feedstock for lapack? I'm thinking this could/should be made more explicit, no? Will try for a patch an explanatory comment...

Edit: figured out why we need the sources at least (linking & testing)
Edit2: I think the penny may finally be dropping. 😅
netlib must be installed in a separate env to link from during the build; which can then be replaced at runtime by another implementation.

[h-vetinari]

OK, I've had a few pennies drop (see edits above), but now that I was trying to put this into words, I still have to wonder:

Why do we link against netlib at all if build_pkg.(sh|bat) will immediately replace it? Yes, there is a testrun of the netlib-packages being performed, but why not do that (including more_testing.diff) in the lapack-feedstock?

What am I (still) missing @isuruf?

[h-vetinari]

On another note: After some tries, 6b4fbef now correctly aborts windows builds on errors within build.sh as well.

[isuruf]

For testing, what we do here is, we build the test-suite of netlib and then we replace the implementation with openblas or blis or mkl and run the test suite to see if changing the blas implementation under the hood actually does work.

[h-vetinari]

For testing, what we do here is, we build the test-suite of netlib and then we replace the implementation with openblas or blis or mkl and run the test suite to see if changing the blas implementation under the hood actually does work.

Understood, my point was that the test suite for the netlib implementation is already run in the lapack-feestock, and just running the tests here with openblas or blis or mkl should be enough, no?

[isuruf]

We are running the netlib test suite with openblas, etc. (We aren't running netlib test suite with netlib) This is done to check that these implementations are indeed compatible.

[h-vetinari]

OK, that makes sense! Thanks for the explanation.

[h-vetinari]

@isuruf
I tried to put what I understood in an explanatory comment (see 316649a). Happy to iterate if I'm still not getting something, but I'd hope that this can be included so that the next person looking at this recipe might be less lost than I am. ;-)

[h-vetinari]

Superseded by #52.