Enable non-standard OpenBLAS extensions v2 #1572
Conversation
We introduce openblas_full, as an alternative to openblas, and load the extra functions there.
openblas_full is an alternative to openblas that doesn't skip any function provided by openblas, except deprecated functions. It includes functions that are not present in Accelerate and/or MKL, but are included in OpenBLAS as an useful addition to the netlib BLAS interface.
... and just redefines map().
|
FYI the following fail was due to a download (networking) fail, not related to the relevant code itself. |
openblas/src/main/java/org/bytedeco/openblas/presets/openblas_nolapack.java
Outdated
Show resolved
Hide resolved
|
I think I got it working. Could you check that the functions you want are all there? |
|
As soon as it appears in the snapshot repo (or is there a way to check right now?) |
|
I checked for a few of them and they are present. I'll test how they work when they appear in the snapshot repo, but I don't see why they wouldn't!. Thanks! |
|
Nope, it doesn't look like it's going to work that easily... |
|
Why? (the failing build is due to a download issue, if you are referring to that) |
|
I see what you mean now. As a first, step, maybe it would be good if we just skipped these functions. As a second step, it seems that the cause is some misconfiguration between what should be prefixed with LAPACK_ vs LAPACKE_ Fox example, LAPACK_sgerfsx can be found in Opelblas source, just as LAPACKE_sgerfsx, |
|
My latest version passes the build phase, I just don't know where to look for the generated Java class to check whether everything is really there. |
|
I've updated the files, but you could set CI_DEPLOY_USERNAME and CI_DEPLOY_PASSWORD to get the files deployed to your Sonatype OSSRH account: |
|
Nope, the functions are not there. Maybe we should just duplicate the code, instead of inheriting, or we should have a plain base class with common methods, and then inherit independent classes openblas_nolapack and openblas_full from it?... |
|
You can do whatever you want, but if your hack is hard to maintain, and you are not there to maintain it, I will simply disable it when it breaks on the next release. |
|
I will maintain it, and I will try to improve it when I learn more JavaCPP (which I plan to do in a few months). But it even won't be a hack, it will just be a bit repetitive. |
|
Of course, if you can offer some hints about what could be a cause of these methods not being in the generated code, that would help me a lot. |
|
If it's repetitive code, then just use methods and variables, etc. I will not merge anything that we can obviously simplify in the first place |
The second try of the #1571
The macos build passed, so I'm opening the PR so you can see whether it now works with the changes you suggested (mapCommon).
I've tried to build everything on my machine, but the openblas build fails (independently of this change) due to some LLVM error that is probably related to some mismatch in I-don-t-know-which combination of native compilers, so I couldn't reach the Java gen stage and see how the final opencl_java class looks like. That's why I'm opening this PR. (btw I've tried the docker way too, as per JavaCPP guide, but then some internal docker stuff didn't work. I couldn't solve it right now).