New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mxnet: use openblas, fix build #87118
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should keep using the virtual package, so that if someone overlays mkl
as the blas
implementation mxnet
will pick it up correctly.
Sometimes, we need the specific provider package in buildInputs as well, to get things like cmake hooks or path searches working. The way to do that is to also add blas.provider
to the buildInputs
, which will cleanly and consistently handle the choice.
CC @matthewbauer I'm pretty sure the above is correct; I had to do something similar for pytorch
. Perhaps we should add to the manual?
@@ -1,5 +1,5 @@ | |||
{ config, stdenv, lib, fetchurl, bash, cmake | |||
, opencv3, gtest, blas, perl | |||
, opencv3, gtest, openblas, perl |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
, opencv3, gtest, openblas, perl | |
, opencv3, gtest, blas, perl |
@@ -17,7 +17,7 @@ stdenv.mkDerivation rec { | |||
|
|||
nativeBuildInputs = [ cmake perl ]; | |||
|
|||
buildInputs = [ opencv3 gtest blas ] | |||
buildInputs = [ opencv3 gtest openblas ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
buildInputs = [ opencv3 gtest openblas ] | |
buildInputs = [ opencv3 gtest blas blas.provider ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, wasn't aware of the provider usage
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there any need for the actual blas
package/attr set? Seems to build fine with only the provider
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, linking maybe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Build just failed for me; looks like we need to do the same with lapack
to make it visible to the linker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there any need for the actual blas package/attr set? Seems to build fine with only the provider
Not actually sure ... in principle it might be sufficient to just pass in blas.provider
, but it seems reasonable to expose the meta-package as well, as that has the actual public API shared objects defined.
32c28a6
to
1df1507
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mxnet
built on my machine with this update now; kicking off a nixpkgs-review
now.
I'm not a big fan of having to do both |
AFAIK, the |
Result of 1 package marked as broken and skipped:- python27Packages.myfitnesspal 5 packages built:- mxnet - python27Packages.mxnet - python37Packages.mxnet - python37Packages.optuna - python38Packages.mxnet |
I would approve your push, but I can't approve my own PR. Lol |
also, wouldn't it be better to get the
|
the main thing I see, is that the |
Agreed, the current setup is a little clunky, though I'm not sure @matthewbauer anything you think we should change here? |
actually, this is specific to
|
by modifying the |
currently blocked by #87134 |
Yes that sounds right. Something in the manual would be helpful. We may need a "maintainers" section or something since this is more about how you make sure your package is correct vs. just how you use it.
Adding the unversioned library seems like a good idea. |
should I just target staging and get this merged? |
Sounds good, let's just merge this on staging then so it can bake with all the other openblas / numpy changes. and we don't have to remember to circle back to it. |
@GrahamcOfBorg build mxnet |
There's a CI error. |
@GrahamcOfBorg eval |
pretty sure staging was broken at the time of PR creation |
Motivation for this change
noticed it was failing when reviewing #87102
previous failure:
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)